60 Days After Alibaba Enters the Global AI Coding Battlefield | A Conversation with Shutong: Founder of Qoder

十字路口Crossing十字路口Crossing··0·0

"Exactly right. Couldn't be more right."

"Absolutely correct. Beyond correct."

👦🏻 Podcast Interview: Koji, Ronghui

🥷 Edited by: Starry

🧑‍🎨 Layout: NCon

"Absolutely correct. Beyond correct."

This was the simple, unequivocal answer we received when we asked Shutong, founder of Alibaba's Qoder[1] (an Agentic Coding product), about his team's experience charging into the global AI Coding "red ocean" for 60 days.

His confidence stems from an impressive track record: 100,000 users within 5 days of launch, and 500,000 developer users in just 60 days.

AI Coding may be the hottest topic in AI this year.

Cursor hit $500 million in annual revenue and soared to a $10 billion valuation, becoming Silicon Valley's most sought-after unicorn; Anthropic, with its powerful Claude Code, has seen a revenue growth curve steeper than OpenAI's.

In this fiercely contested battlefield, where does a latecomer like Alibaba have a shot?

This week, we invited the former multi-year technical lead for Alibaba's "Singles' Day" shopping festival, and the earliest pioneer of cloud-native transformation across China's entire tech industry, to share an exclusive look at what's behind Qoder's "strong start" — the product thinking, technical architecture, and organizational capabilities that made it possible.

🎥 This episode was recorded at AI Hacker House. The video podcast will be released on Koji's Xiaohongshu, Bilibili, WeChat Channels, and YouTube.

Listen on WeChat:

Listen on Xiaoyuzhou:

The full interview is quite long (19,299 characters). Here's a table of contents:

🟢 Rapid Fire: Age, alma mater, MBTI and zodiac sign, one-sentence product pitch, revenue and profit, team size, exploratory work before Qoder

🟢 The AI Coding Landscape: From 0 to 1 vs. From 1 to 100

A typical user journey: first use AI to generate a website prototype, then when it starts generating business value, switch to more professional tools for maintenance and iteration. What does this reveal?

  • Three dominant forms in the AI coding space: "idea-to-reality" tools for creators, "efficiency boosters" for professional developers, and "digital employees" that directly replace human labor.
  • Why do all forms of AI coding tools inevitably converge toward a "grand unification"?
  • "AI coding tools without self-developed models are just working for the model vendors" — why will companies like Cursor inevitably build their own model capabilities?
  • What natural advantages do tech giants have in building AI coding products? Beyond cost, the critical factor is end-to-end joint optimization with the model.

🟢 Breaking Through the Red Ocean: Qoder's Strategic Choices

While everyone else was picking the low-hanging fruit, we chose to attack the high ground directly.

  • A pivotal strategic choice: rather than chasing the "flashy" scenario of generating new projects from 0 to 1, we cut directly into "real-world software" development — where developers spend 95% of their time.
  • Why do we define Qoder as an "agentic programming platform"? Because the future of development collaboration will evolve from "human-machine pairing" to "AI autonomous programming."
  • "I don't do it, the agent does" — this is an entirely new development paradigm.
  • The reason for forging a different path: as a latecomer, we wanted to quickly carve out our own niche in the red ocean through differentiated positioning.

🟢 The Requirements Doc Is What Matters Most!

AI isn't just good at writing code — it's even better at writing requirements documents.

  • From "prompt engineering" to "context engineering": how do we enable AI Agents to independently complete larger, more complex tasks? The answer is Spec-Driven development.
  • A typical Spec-Driven workflow: user submits a one-sentence requirement → "Documentation Agent" auto-generates a detailed design doc → upon user confirmation, "Code Agent" executes over an extended period.
  • This essentially mirrors the real-world workflow of "boss states requirement → product manager writes PRD → engineer develops" — now AI-ified.

🟢 Product Philosophy: From "Don't Break Flow" to "Give You Control"

In the AI era, developers are forced into "pair programming" — the completely uninterrupted "flow state" of the past is becoming impossible to maintain.

  • A new tension in the AI era: you need to provide capable tools, yet those tools inevitably interrupt the user's flow. How to balance?
  • Our answer: rather than futilely pursuing zero interruptions, give users complete "sense of control" — make them the manager of the AI Agent.
  • A counterintuitive product design: Why does Qoder still not let users choose their model? Because "machine selection beats human selection," and it prevents users from becoming "model testers" suffering decision fatigue.
  • How do we balance the "impossible triangle" of performance, efficiency, and cost? The core lies in meticulous "context engineering."

🟢 Organization and Methods: How to Support a Lightning War?

Why could Qoder get off the ground so fast? Because we didn't start from zero — we integrated talent and technical assets from multiple mature teams within Alibaba.

  • From Tongyi Lingma serving the China market, to Qoder going global — what organizational and strategic evolution happened behind the scenes?
  • A critical decision: to seize the global market window, we first serve developers with the best models available worldwide, while "using battle to sustain battle" — buying time for our self-developed models to mature.
  • "It's an independently operated business unit" — how does internal startup incubation within a tech giant, through organizational design, truly "shed the baggage" and achieve startup-level agility?

🟢 Repo Wiki: The Secret Weapon for Taming "Legacy Code"

In our very first computer science class, the professor told us to write good documentation and comments. Yet almost no team actually does it. This is such an obvious need — why did no one do it before?

  • The first principles behind developing Repo Wiki: "Documentation lies, but code is always current."
  • How do we use AI to deconstruct "legacy code"? By analyzing the current code slice and all historical commit records, we reconstruct the system's design philosophy and business logic.
  • How do we ensure this documentation never goes stale? As the codebase changes, the AI incrementally updates this "living document" in real time.
  • Why are we confident we can build a moat? Because this isn't an atomic capability — it's an entire deeply customized system of models, agents, and Git-integrated team collaboration workflows.

🟢 1024 Message: How Do Programmers Evolve in the AI Era?

Programmers may be the group least afraid of learning — and that is precisely our greatest advantage in the AI era.

  • Will AI replace programmers? No. And Jevons paradox tells us: when costs drop, demand explodes. The number of programmers may actually grow.
  • What is the core competency of the future engineer? Shifting from pure coding ability to composite capabilities: requirement insight, overall design, result validation.
  • Advice for first-year CS students: embrace AI, but double down on computer architecture — you need to know when AI is "blowing smoke."

🟢 Singles' Day Memories: A Top Architect's Two "Gaokao" Moments

The boss gave us a crazy target: 50x traffic spike for Singles' Day, without spending an extra dime. We pulled it off.

  • "Create countless Singles' Days before the real one" — how did "full-link stress testing" as a radical medicine allow us to rehearse repeatedly under real traffic, taming thousands of systems?
  • How do technical people forever "demand dividends from technology"? From solving stability problems to ruthlessly optimizing costs through containerization and cloud-native tech — the complete methodology behind it.
  • The growth path of a top architect: from solving a technical problem, to building a technical system, to productizing and commercializing that technical capability, to ultimately seeking a larger stage.

Rapid Fire

👦🏻 Koji

Let's start with rapid fire. Shutong, how old are you?

👦🏻 Shutong

👦🏻 Koji

Alma mater?

👦🏻 Shutong

Jilin University, Computer Science.

👦🏻 Koji

Pitch Qoder in one sentence.

👦🏻 Shutong

A future-facing product, positioned as the next-generation agentic programming platform.

👦🏻 Koji

What were you doing before Qoder?

👦🏻 Shutong

I spent 16 years at Alibaba, working on Taobao's architecture and serving as the technical lead for Double 11. Over the past decade, I focused on containerization and cloud-native technology, including the evolution of Alibaba Cloud's native tech stack and productizing related technologies.

👦🏻 Koji

What's your MBTI and zodiac sign?

👦🏻 Shutong

INTJ — the Architect, which fits my work perfectly. Scorpio.

👦🏻 Koji

Can you share Qoder's current user scale and commercial progress?

👦🏻 Shutong

We've reached 500,000 active developers two months since launch, and commercial progress is on track.

AI Coding Panorama: From 0 to 1 vs. From 1 to 100

👦🏻 Koji

Could you start by mapping out the AI Coding landscape for us? Give us the lay of the land.

👦🏻 Shutong

There's broad consensus now that large language models are exceptionally strong at coding. Naturally, different teams are building products in this direction. And that leads to an obvious question: how do you turn a one-sentence request, an idea, into a working piece of software or service — say, a website. Products like Lovable and bolt.new serve creators or "generalist developers."

But these products often face a problem — short lifecycles. Everyone has ideas now, everyone can execute, and you can generate software for a few dollars. But if it only solves your own small need, it won't survive long-term. So another category emerged: platforms that let users publish their creations for others to buy and reuse, like "Youware" domestically. These represent the "from 0 to 1" form of AI Coding — using AI to rapidly generate basic software services.

Another category is professional all-in-one tools like Cursor and Claude Code. These target the 30 million professional developers in the industry — people who produce massive amounts of code and software daily, creating commercial value. The question is how to make them more efficient. Since models already surpass individual human coding ability, the key is integrating them into developers' daily workflows to boost productivity and output.

So these products focus more on completion, agentic collaborative development, even autonomous programming — professional scenarios. They mainly solve "from 1 to 10" or "from 10 to 100" problems — once software starts generating commercial value, it needs long-term iteration, deep understanding, continuous maintenance, longer lifecycles, and higher demands on AI tools.

So a typical user pattern now is: start with something like Lovable to generate a website or service; when it's time to commercialize and scale, switch to Cursor to modify and maintain. As complexity rises, the "one-sentence generation" approach becomes insufficient — you have to move into professional development.

Looking further ahead, there's Devin — its positioning shifts from "helping developers be more efficient" to "directly providing digital employees." The goal is to function like a full employee or intern: take on complete tasks, work long-term, coordinate multi-role resources, and deliver results. This is a relatively forward-looking direction. Products like our Qoder are gradually gaining these capabilities too.

So overall, AI Coding product forms can be divided into three stages — "from 0 to 1," "from 1 to 10," and "from 10 to 100."

👦🏻 Koji

Do you think everything will eventually converge into one unified solution?

👦🏻 Shutong

Very likely. The core need is using coding to provide software services that serve business scenarios and create commercial value. Capabilities will keep strengthening, forms will diversify, so convergence is the direction.

👩🏻 Ronghui

I'm curious — what role do models play in this eventual convergence? Some say Cursor will eventually build its own model.

👦🏻 Shutong

Models matter enormously. This gets back to why we believe Alibaba has the opportunity to build stronger products and IP — because we have model capabilities.

Without model capabilities, you're seen as a "wrapper product," with high costs, unable to do joint optimization with the model, and it affects your valuation and revenue.

With your own model, you can do joint optimization — improving performance, cost, and efficiency — which has major impact on enterprise profitability. You're not just driving traffic to model vendors. So we judge that these products will inevitably build their own models.

Breaking Through the Red Sea: Qoder's Strategic Choices

👦🏻 Koji

Qoder launched in August 2025. Tell us about entering what was already a red-ocean market — what unique competitive angle and strategy did you choose to quickly carve out your own lane in this intense battlefield?

👦🏻 Shutong

Good question. When we launched, there were already many competing products in the industry — it was genuinely a red ocean. But we had our own distinctive read on the market and product positioning. Following the logic I just laid out: Vibe Coding has gained wide acceptance, and it's impressive that one sentence can create a software service.

But we found that over 95% of professional developers maintain real software. Real software means software that actually generates commercial value. Once it generates commercial value, you're accountable to users and customers. It requires serious modification, iteration, and evolution — no room for failures — and carries lots of historical accumulation, maybe five or ten years deep. This legacy code can't be changed recklessly; you can't improvise or hallucinate. So this is the high-value ground, because it truly supports the information industry's sustained value creation.

Many tools today enter through Vibe Coding. We chose to enter through real software — that's our first point of differentiation, and what sets us apart.

We also saw certain trends. AI Coding started with humans主导 writing code, AI assisting with completion — the assistance phase, like the familiar Tab Tab in the industry. The second phase is collaborative programming, where humans and agents interact synchronously — filling in documentation, adding comments, or completing features to finish tasks and tests.

As models and agents evolve, new collaboration patterns emerge. We call this AI autonomous programming — where AI + Agent can form digital employees that complete tasks fully and asynchronously. Developers essentially gain an assistant or team member, an AI corps that can handle whole chunks of work.

We believe this trend has already arrived, so we positioned our product around two cores: facing real software, and an agentic programming platform — "I don't do it, the agent does." This is how we define the future of development collaboration. Entering from these two points creates clear differentiation from existing products.

👦🏻 Koji

This insight comes from underlying user, business, and market needs. But why weren't more people doing software maintenance from the start? Not cool enough, or too hard?

👦🏻 Shutong

Both. Everyone prefers creative work — generating a beautiful website in one sentence is satisfying, and users like those products more. But there are many paths to leverage large language models. As latecomers, the low-hanging fruit was already picked. We wanted to attack the high-value ground directly, entering real software scenarios.

The developer work phases I described — from assistance to collaboration to autonomy — all exist simultaneously. We position ourselves as the next-generation autonomous programming platform, but we're not only doing the autonomous phase. We do all three phases, because we need to serve the broadest spectrum of developers, wherever they are.

Chinese developers and overseas developers are at different stages today. China's models and overseas models are at different development stages too. Through extensive customer interaction, we clearly see usage differences. For example, in China, Q&A-style usage is more common — users ask questions, get model responses, then modify code themselves. Overseas has already advanced to letting models directly modify complete code, with less human involvement.

👩🏻 Ronghui

So there will be differentiation tailored to China.

👦🏻 Shutong

Yes, there will be differentiation.

👦🏻 Koji

Qoder was a global-market product from day one, right? No separate China version and international version.

👦🏻 Shutong

Correct. We must serve the broad spectrum of developers, so all these capability types need to be present. Users can combine capabilities according to their usage habits. If you use completion heavily, use completion. If you use Ask heavily, use Ask. If Chinese developers quickly embrace advanced productivity tools, they can use autonomous programming directly. We have all these capabilities.

Our forms are also diverse: we have an IDE, we've released a CLI, we'll release JetBrains plugins, and we'll integrate across different scenarios. For example, in work pipelines or internal platforms, using programming agents to delegate tasks, track progress, and verify results. Meeting diverse coding and software production needs from different angles and forms. Supporting multimodal inputs like images and voice is also about providing different touchpoints. This is the product form we want to present.

👦🏻 Koji

Who do people most often compare you to?

👦🏻 Shutong

Still Cursor mostly, but Cursor is much larger — we're still catching up.

👦🏻 Koji

Your biggest differences from Cursor are: first, making tacit knowledge visible to help maintain existing software; second, agents and Quest mode, more independently completing programming tasks.

👦🏻 Shutong

We've done extensive work on this, including what we advocate as Spec-driven development. Spec-driven means requirements-document-driven — also to enable agents to independently complete large chunks of work over extended periods.

The Requirements Document Is Everything!

👦🏻 Koji

Can you elaborate? When you say "requirements-document-driven," what does that workflow look like? What product features does it correspond to?

👦🏻 Shutong

It's an evolutionary process. From prompt engineering to context engineering — the essence is building better context so large language models can produce larger outputs in a controlled way and work for longer periods. We must use Spec-driven to push Agent work, because to have it complete large tasks, the requirements must be expressed clearly.

Requirements include business insight, business logic design, technical patterns, technical architecture choices, design specifications, module design, implementation requirements, and so on. We decompose tasks clearly through technical documentation and business architecture design. This process is also an interaction with the model. Once the model understands the task, it clarifies requirements content and steps. This essentially maps the original human-to-human collaboration pattern.

For example, when three people develop software together, one person proposes requirements, then conducts research, confirms the technical solution, writes a clear requirements document (PRD), defines acceptance criteria, and data integration methods — after which the programmer implements and iterates toward market launch. This workflow is mapped onto collaboration with large language models: once the model receives a detailed Spec, it can autonomously complete tasks in phases over extended periods, self-checking whether results match the developer's expectations. Thus, Spec-driven development is the inevitable choice for achieving long-term autonomous collaboration with agents.

👩🏻 Ronghui

It's essentially mapping the real workflow of traditional team-based collaborative development.

👦🏻 Shutong

But there are also some small tricks here. For instance, many people don't want to write requirements documents, but large language models are not only good at writing code — they're also good at writing requirements documents.

👦🏻 Koji

I noticed that when I use Qoder, after I give it an idea, the first thing it does is help me write a document.

👦🏻 Shutong

To write good Spec documents, we've built some agents. Although they're not explicitly shown in the feature modules, they can break down a one-sentence requirement into a standardized design document. The user then makes minor adjustments or adds confirmations, and after confirmation, execution can begin — thereby driving the agent to carry out long-term tasks.

👦🏻 Koji

Previously I tried a product from Wiki. It kept the requirements document and visual mockups permanently in a corner of the infinite canvas, forming something like a "constitution." Any subsequent page or modification would reference it.

👦🏻 Shutong

This is a common way to constrain model behavior. In Qoder, we also achieve similar constraints through system prompts and memory mechanisms. We provide many handy tools that let developers define rules — what can and cannot be done — and write these into Rules. This way the model won't deviate from the task during execution, just like how every company first "sets ground rules." We also provide these capabilities to users through open interfaces.

Product Philosophy: From "Don't Interrupt Flow" to "Give You a Sense of Control"

👩🏻 Ronghui

Beyond this mapping of traditional development workflows, have you made any new adjustments or improvements?

👦🏻 Shutong

We've developed some new development approaches suited to the AI era. When building tools in the past, one core philosophy was emphasized: don't interrupt the user's flow, let them complete work continuously without interference. Early VS Code, for example, was built on this philosophy of "not interrupting user flow" — keeping users working continuously within a one-stop platform.

But in the AI era, this "continuous flow" is hard to maintain because there are more tools, development has become pair programming or even multi-party collaboration, and frequent interaction between humans and agents naturally produces feedback, revisions, and iterations — things like "I'm not satisfied with this part, please change it" or "add a feature here." Collaboration brings productivity gains but also attention-switching costs. At the same time, you have to manage agent behavior, like the Rules constraints I just mentioned.

We've also designed agents to understand and adapt to developer preferences. They summarize developer behavior patterns: what they want, what they don't want, what they can accept, what they'll reject — and write these summaries into memory. But developers don't necessarily always agree with these inferences, so they can edit and modify the agent's memory.

Meanwhile, users also consider cost control — things like compressing context, switching models, restarting sessions to improve efficiency. So you could say that in the AI era, users' "flow mode" has changed. They're not just developing; they're also scheduling AI resources, managing agent behavior, and controlling costs. So we need to find a balance in the product: providing handy tools and high productivity without making users feel constantly interrupted or losing control.

👦🏻 Koji

Sounds like maintaining flow isn't easy, because there are many reasons for interruption, and they're often unavoidable.

👦🏻 Shutong

Yes, so we need to give users a "sense of control." When developers can control the entire process, including agent behavior and task direction, even frequent interactions can still provide a good experience. This is the core product philosophy after the shift in development collaboration patterns in the AI era.

👦🏻 Koji

Is there a concrete example? What special designs or trade-offs have you made to help users enter a flow state?

👦🏻 Shutong

For every feature, we strictly evaluate two things: first, does it interrupt the user? Second, does it increase cognitive load? We believe that in AI collaborative development mode, interruptions are objectively unavoidable, but we must never increase cognitive load — that is, don't make users struggle to figure out how to use the product. The interaction must be natural and direct. Once you make users stop to understand the interface or feature logic, you've violated good product design principles.

👦🏻 Koji

That reminds me of a book from when I was a product manager — Don't Make Me Think. The whole book's core message is just one sentence: don't make the user think.

👦🏻 Shutong

Right, we hold the same principle. For example, you may have noticed that Qoder doesn't provide a model selection feature — this is actually to implement this philosophy.

👦🏻 Koji

That's indeed quite interesting. Because people default to assuming you use Qwen's models, but I saw on your official website that it says — use the best model, not "a certain company's" model, and you don't let users choose themselves.

👦🏻 Shutong

Exactly. We have a highest principle: integrate the world's best models and let users directly get the best results. So Qoder's model pool includes both top overseas models and domestic models. But users don't need to manually select models, because model selection itself is a serious interruption.

If you list 40 models like Cursor does and let users choose, they have to stop and learn about model pricing, speed, context length, areas of expertise, and repeatedly test and rank them. This directly turns developers into "model testing engineers" — a huge loss of experience.

👦🏻 Koji

This is actually also a user expectation — they want a sense of control. Especially when a new version appears on the market, say Claude releases 5.0, and everyone's saying performance improved tenfold, earth-shattering. Then everyone wants to try it, but if they can't directly select 5.0 in Qoder, they'll feel restricted and might even churn. What do you think?

👦🏻 Shutong

We prefer to answer users' questions with results. That is, when users ask the same question in Qoder, are the results not inferior to those products that "let you freely choose models"? We believe results speak for themselves.

Actually, in this category of AI coding products, there's a "performance impossible triangle": performance, efficiency, and cost. If you want fast and cheap, it may not be powerful enough; if you want good performance and high efficiency, costs will rise. We're constantly balancing these three.

So our thinking is: when a better model emerges, even if we don't let users manually select it, our results can't be worse than others', and should be even better.

👩🏻 Ronghui

Then will this impossible triangle ever become possible?

👦🏻 Shutong

The core challenge lies in "context engineering." Whoever can better construct context can find balance between performance, cost, and efficiency.

Additionally, regarding "model selectors," our philosophy is "machine selection is better than human selection." The second philosophy is "platform support is better than individual choice."

We have a large user base and real usage data, so we can know at a statistical level which model is most suitable for different scenarios. If we let users manually select, first it interrupts their thinking, and second it's unrealistic — no one can switch models for every single question. Most people start a new session, pick a model, and stick with it. So we want the system to automatically judge and select the most suitable model for each question. This gives better user experience and results.

This is also Qoder's biggest difference from other products: we let results do the talking.

👩🏻 Ronghui

Then how can users feel this effect without knowing about you beforehand?

👦🏻 Shutong

Our next step will be to open a "real-world software evaluation benchmark." This will let users compare different products' effects on the same dataset, including stability, cost, timeliness, and final result satisfaction. Philosophy is one thing, but actual product performance is what matters. Subjective user experience is one form of evaluation, but this benchmark makes results more objective and data-driven.

👩🏻 Ronghui

What does this product mean for Alibaba?

👦🏻 Shutong

Our CEO Eddie Wu actually said: "Coding is the inevitable path to AGI."

For us, Qoder is an important vehicle for helping large models improve end-to-end capabilities through actual coding tasks. It serves developers and also serves broader scenarios. Strategically, it's an important component of Alibaba's entire AI system. Of course, how much impact it can ultimately have depends on how much market share our product can achieve.

👦🏻 Koji

Mm, it's already very good now, a great starting point.

👩🏻 Ronghui

When you first took over this product, was there an internal goal?

👦🏻 Shutong

Yes, our vision is to become "top three in the world."

👩🏻 Ronghui

Then what rank are you now?

👦🏻 Shutong

It's far from time to rank. Right now everyone has just finished the first kilometer of a marathon; we still have to see stamina, resources, and acceleration.

👦🏻 Koji

Generally when you hear "top three," the first reaction is "third" (laughs).

👦🏻 Shutong

Actually the difference isn't big. Top three and third are similar in meaning. The key is that this is a vision. Market competition is indeed fierce, but we also have confidence. Although the product has only been live for two months, developer feedback has been very positive. From the start we positioned ourselves on "building real software, producing high-value output," and this has been recognized.

We have technical advantages — whether it's Alibaba's overall technical capabilities, the depth of our model R&D team, or upstream and downstream collaboration capabilities — all of which can help us continuously optimize on performance, efficiency, and cost. Going forward we'll also continue innovating on product form and user interface, better integrating underlying model capabilities, context construction, and tools to form more diverse competitive advantages.

So we believe that compared to similar domestic and international products, we still have strong stamina and unique advantages, which is the source of our confidence.

👦🏻 Koji

What was the cycle like from project initiation to launch?

👦🏻 Shutong

It all happened in 2025.

👦🏻 Koji

Very fast.

👩🏻 Ronghui

Launching in August.

Organization and Methods: What Supports a Lightning War?

👦🏻 Koji

I know Alibaba already had a very successful coding product before this — Tongyi Lingma. With Lingma already in place, why build Qoder?

👦🏻 Shutong

Yes, Lingma has been in the domestic market for over two years and has genuinely earned strong recognition from developers, with the top market share among plugin stores. So when we discussed next steps, it wasn't simply about adding another product — we went back to fundamentals and made some core judgments.

For instance, what brand should we use for global expansion? What should the product form be? Continue as a plugin? Or an IDE? Or command line? Or agent-based output? And how should we approach models — purely self-developed, or integrating the best models globally?

We discussed these questions in depth. What ultimately drove our decision to build Qoder was a market-based judgment: developers will always choose the best product — the one that understands them most deeply and delivers the greatest value. So we decided to position Qoder as our global-facing form.

Lingma we positioned for the China market, while also helping our self-developed models accumulate time and data — assuming Alibaba's models reach global leadership within a year, Qoder would of course fully adopt them. But we can't wait for models to become world-class before serving developers. By then the opportunity would be gone. We must serve developers first, then catch up on model capabilities.

Once this path was set, the team's execution drive became very strong, because we know the market well enough and have experience building successful developer products, which made our conviction around Qoder firm.

👦🏻 Koji

So this team wasn't assembled from scratch — it continued from the Lingma period?

👦🏻 Shutong

Right, the core team carried over, with some other excellent people joining, so we got off the ground very quickly. Everyone's also been quite driven, because we genuinely believe in the mission of technology changing the world. And when you actually encounter an opportunity to let technology impact global developers, people's level of commitment is completely different.

👩🏻 Ronghui

Then I'm curious — when this project was approved, did you actively ask for it, or was it assigned by the company?

👦🏻 Shutong

I'd call it mutual attraction (laughs). Lingma itself was already a solid achievement, and extending it into a global product — we genuinely felt our team was the most suitable fit.

👩🏻 Ronghui

And from a branding perspective, the name Qoder seems deliberately designed to avoid strong ties to "Alibaba" or "Tongyi" labels — more like a neutral, purely product-oriented brand.

👦🏻 Shutong

Exactly, that's precisely why we chose this name. Qoder is essentially a homophone of "Coder" — it means programmer. We wanted this product's identity to be very clear: it's not an accessory to some model, nor an extension of some platform, but a tool belonging to developers — a programmer you carry with you, one at home, one on your team, without extra brand constraints, so it has more room to grow.

👩🏻 Ronghui

Then where does it sit within Alibaba's overall AI strategy?

👦🏻 Shutong

Right, an important point is actually resource support. Including unbundling targets, improving team efficiency — the company has given us considerable space. We've also shed some baggage to face the market more directly, looking at why competitors are running fast and how we can run fast too.

This has been crucial for us. Because outsiders might worry that big companies have complex processes, cumbersome mechanisms, many constraints — won't that slow down efficiency? Especially for a from-zero-to-one product, this concern is quite realistic. But our current state is more like "startup within a big company." We have resource support alongside sufficient openness and flexibility — I think this is the best form of support.

Whether in resource support, mechanism flexibility, or decision-making efficiency, we've received substantial authorization. Many people worry that big companies doing innovation get dragged down by process, but with Qoder we've been very fortunate — what the company gave us is a startup-style mechanism: remove baggage, rapid trial and error, face global competition. I think this is the prerequisite for our ability to fight a lightning war.

👦🏻 Koji

When Qoder launched, people said all three BAT companies had entered the AI Coding space, while overseas there was Anthropic's Claude Code, OpenAI's tools — in this situation, do startups still have opportunities?

👦🏻 Shutong

Honestly, looking at the current landscape, opportunities for startups are increasingly scarce.

On one hand, even though AI Coding sounds like "a wrapper product around large models," the investment required is actually enormous — whether in team scale, compute resources, or capital costs. To build a truly scalable product, it's almost impossible without capital backing.

On the other hand, the advantages of large platforms are continuously amplifying, forming their own flywheel effects. For example, Claude Code or GPT-5's CodeX have natural advantages. Because they use their own models, compute costs are low; while teams like Cursor using external models face costs several times higher. So large platforms can achieve "good performance, low cost, and decent efficiency" all at once. Because their compute resources and cluster infrastructure are already sunk costs, while selling APIs can charge per use — this creates structural advantages.

Of course, early startups had a window. Cursor, or early Lovable — they defined this category very early, established product form, plus rapid iteration rhythm, forming first-mover advantages.

But now if another startup wants to enter, unless they can create a completely new model, otherwise under the same product logic, competing simultaneously against big tech, model companies, and these already-momentum-gaining firms — it's genuinely difficult to have an advantage.

👩🏻 Ronghui

Then domestically, from a product perspective, who do you think is doing best?

👦🏻 Shutong

We certainly think we're doing best (laughs). But I feel competitors in this space are all worthy of respect. Everyone has different philosophies, has built products of different forms, and is meeting different developer needs.

From our perspective, at this stage it's not yet "fight to the death" competition, but more like differentiation and exploration within a massive domain. Because globally, professional developers may only cover a third of the entire market — two-thirds of potential users haven't been reached.

So we haven't reached that extreme involution, extreme cost-performance competition stage yet. Everyone is still blooming in diverse forms, each finding their own breakthrough point.

Repo Wiki: The Secret Weapon for Tackling "Legacy Code"

👦🏻 Koji

Do you think user retention is a concern for AI Coding products? After all, the code repository is right there — today I can use Qoder, tomorrow I can easily switch back to Cursor, especially if Cursor integrates the latest and strongest model.

👦🏻 Shutong

We've discussed this internally. For example, the code visualization capability you mentioned — what we call Repo Wiki. We discussed whether such visualized content could only be viewed in Qoder. Ultimately we concluded this is impossible, it must be open, users should be able to export anytime, it belongs to users, it's user assets.

So our most straightforward thinking isn't "how to forcibly retain users," but "what approach makes users want to stay." We believe true stickiness comes from differentiated capabilities and openness. So we'll persist in two things: first, building differentiated capabilities that others don't have; second, maintaining openness, not building closed systems.

👦🏻 Koji

Many people mention that Qoder's positive reviews come from you solving the "legacy code maintenance" problem. For example, I take over an old project that 100 developers have modified, with complex code structure and hard-to-understand logic — casually fixing one bug might trigger a cascade of new bugs. Repo Wiki's value is right here. But this feature looks simple; building it must be hard, right? How did you sort out complex, messy legacy code?

👦🏻 Shutong

Actually, the kind of "messy, chaotic, high-workload" tasks I just mentioned are precisely what large language models excel at. Our entire implementation system is built on large models, but on this foundation, we've also constructed our own series of agents.

One of our core judgments is: for developers, the most real-time, most alive, most valuable沉淀 is actually the code itself. Because when the boss requests a feature change, everyone immediately changes code, but few people同步 update documentation — that's too uneconomical. So code is the most accurate reflection of current business state, the endpoint of consensus among product managers, designers, and engineers.

Based on this logic, our starting point is from code itself. Code isn't just static content; it also contains commit history, change records, version evolution and other dynamic information. By analyzing these slices and change trajectories, we form understanding of the entire codebase: its design logic, evolution脉络, architecture structure, business relationships, etc., and based on this generate a "living document" that surpasses traditional documentation value.

Every line, every character of this document is generated by large language models, without adding extra burden to developers. Meanwhile, as the codebase changes with commits, it also updates in real-time, incrementally, automatically. That is, this document can be viewed as the most valuable and always-alive documentation in the system, but it's generated by AI.

👦🏻 Koji

This is indeed highly needed. Like our first computer science class, the teacher said to write good documentation, good comments. After starting work, efficiency is often affected by incomplete comments and missing documentation. Many teams have tried establishing documentation standards, doing code reviews to strengthen this, but it's hard to sustain. After all, under the tradeoff between speed pressure and human nature, almost no team can maintain high-quality documentation long-term.

Then I'm quite curious — such an obvious need, why didn't Cursor or other peers do this before? If one day they want to, can they reach your current level? Or do we have some unique "secret recipe" or technical system that makes it hard for others to catch up?

👦🏻 Shutong

Definitely not that easy. Implementing the "feature" itself isn't hard; what's hard is how to achieve it fast, well, and cheap — both low-cost operation and precise understanding of code history and context.

We've actually done substantial customization work on this. First, we have models specifically tuned for this purpose, and a customized agent system. The entire system has supporting maintenance and usage workflows, deeply embedded in developers' daily work processes.

On the technical side, we've done a lot of optimization, but business scenarios matter just as much. We made this system a genuine collaboration tool: handoff modules, employee onboarding and offboarding, taking over new projects — all of these can start from this "AI document."

Additionally, we integrated deeply with Git repositories, so multi-person teams can share and export the same intelligent document without regenerating it repeatedly. This is no longer an atomic capability, but a complete, systematic workflow.

Precisely because of this, it has formed a fairly robust systemic moat.

👦🏻 Koji

And it's already coupled with Qoder's other workflows, so it's actually not easy for others to replicate even if they wanted to.

👦🏻 Shutong

Right. For example, when we first launched, generating a Repo Wiki took 60 minutes. The latest version has cut that to one-fifth of the time. Although these tasks involve massive token volumes and high compute costs, our model customization and optimization have dramatically improved efficiency.

👦🏻 Koji

Everyone knows your Repo Wiki works quite well, but I'm curious — during development, how did you evaluate whether it was "good" or not? Like, if you generate an image or answer a question, quality is obvious at a glance. But if I give you a codebase and ask you to generate documentation, judging "good" versus "bad" becomes much more complex. Especially since you had to internally test results across hundreds or even thousands of codebases — how did you design this evaluation system?

👦🏻 Shutong

That's an excellent question. In fact, the entire large language model field faces similar challenges — the "cross-evaluation" problem: who's actually better? And in which scenarios?

We mainly use two dimensions for evaluation.

The first is self-comparison — new version versus previous version: is this one better, more precise, more stable?

The second is external comparison — pitting our customized model against top overseas models to see whose generation quality is superior.

For determining "good" versus "bad," we don't rely purely on manual judgment. We combine multiple approaches:

  • On one hand, there is human involvement — engineers and annotation teams do subjective assessments on batches of samples;
  • On the other hand, we've introduced a mechanism similar to reinforcement learning, using a reward model to judge which results are "better": for instance, if something is read, adopted, or cited by users at higher rates, the system marks it as "good."
  • We also collect user annotations and feedback to continuously train this "quality-judgment model."

So overall, this is a combination of "human evaluation + system self-learning." In the earliest versions, we focused more on comparing our model's performance against overseas models; only later did we gradually develop a systematic automated evaluation framework.

👩🏻 Ronghui

So what are your goals for the near term, say this year?

👦🏻 Shutong

Our core philosophy is still improving product capabilities. I can share something about our Quest Mode. Quest Mode is an autonomous programming mode — it's our definition or prediction of what future developer workflows will look like. We believe more developers will use this autonomous programming mode in the future: humans act as leaders, AI agents do more of the work.

In this process, we discovered there's a ceiling — human working hours and computer limitations. For example, when I close my laptop or get off work, I can't keep working, but I want the AI to continue. So based on Quest Mode, we built a cloud sandbox environment. Through SPEC, we send the codebase to the cloud so it can run for extended periods. Even when I'm on vacation, it keeps working.

Meanwhile, I can launch ten asynchronous sandboxes running in parallel. This means one person can lead ten agents to complete a set of requirements — a tenfold productivity boost, without sacrificing work-life balance. This model truly breaks through time and space constraints, delivering that tenfold productivity gain, which is why we released this capability.

👦🏻 Koji

Actually Cursor also has agent mode, but it sounds like Qoder and Cursor are quite different in agent mode. You have cloud sandboxes, multi-threading, and other features — besides these, what else is different?

👦🏻 Shutong

Cursor also supports cloud mode, but the implementation differs. It can launch an IDE remotely, whereas we don't have a remote IDE — our remote environment is purely a runtime environment, more flexible with better timeliness.

We don't rely on plugin tools within an IDE. We simply migrate the agent to the cloud, then simultaneously launch multiple parallel sandboxes to execute tasks concurrently — low resource consumption, fast startup. The path choices and implementation approaches are quite different.

👦🏻 Koji

So would you say the relationship between users and Qoder is — the user is the boss, and Qoder is an agent for future independent programming.

Actually Devin and Manus both have similar design philosophies, and they share a common feature: if an agent has been working too long, I can ask it "what are you doing right now? Why are you making me wait so long?" Devin and Manus can both answer, like asking a subordinate — it will pause work and give me a quick report, then I adjust the task and let it continue.

Does Qoder support this kind of feature? Also, what's your view on the future relationship between humans and AI? Not limited to AI coding.

👦🏻 Shutong

We support similar functionality too. Because when agents work for long periods, they can drift off course, or cut corners by skipping tasks. This happens quite commonly.

We create a todo list at the start of a task, and the agent must strictly follow it — no skipping tasks or falsely claiming unfinished tasks are complete. During long tasks, we can check in at any time, and it will output its current workflow. We can also give new instructions and requirements to correct course.

This prevents situations where an agent works for hours only to produce results that have gone off track, wasting everything. So we've built strong capabilities in this area.

👦🏻 Koji

What do you think the future relationship between humans and AI will look like? Not just at the coding level.

👦🏻 Shutong

I still want to start from coding. We believe coding will become the "hands" and "actuator" for large language models, the connector between the digital and physical worlds, helping humans accomplish complex tasks.

Humans will become managers in this picture, setting clear requirements, with different agents understanding and collaborating to complete tasks. People who will be more competitive in future workplaces or business society will definitely be those who can fully harness these AIs — who can manage and coordinate agents well, find business scenarios, and create value.

This is also why we're seeing so many one-person companies — they represent a future where humans and AI collaborate closely, forming organizations with tremendous creativity. Much work gets done through AI collaboration, and this organizational form could become mainstream.

👩🏻 Ronghui

Although it's called Qoder, will you only do coding?

👦🏻 Shutong

Currently we're focused on coding, but the product form and covered scenarios will extend significantly. We build product capabilities from the bottom up — optimizing and customizing above the model level, doing context engineering, forming numerous agents and tools.

Once capabilities lead, product forms and interfaces will expand. The IDE is just the core interface for professional developers, the largest toolset. CLI serves more professional or automated development scenarios. We'll also integrate agents into more pipelines and customized scenarios — you could even summon an agent from your phone or within an app to work for you.

So there will be much more expansion in form. Every small need can be met, scenarios will be fully digitized; complex tasks can also be handled by AI, with agents as the actuators. Scenarios will open up completely — the future definitely won't have only the IDE as a single form.

👩🏻 Ronghui

I feel like Qoder carries a broader mission and more imaginable extensions.

👦🏻 Shutong

Yes, we hope to position ourselves as programming agents above the model level. Our IDE is a programming agent IDE platform, and in the future there will be other platform forms for programming agents.

👦🏻 Koji

The day before we recorded this podcast, we noticed Qoder just released CLI, the command-line mode. We'd like to ask about the background and internal thinking behind this release. You mentioned some of it just now, but anything to add? Also, we'd like to understand whether it has a competitive relationship with Claude Code, and if so, how you compete?

👦🏻 Shutong

Let's start with why we're building this form. It goes back to our original intention for the IDE: we wanted to deliver coding capabilities through the most universal work interface for developers. Since most developers work through an IDE, naturally we had to build an IDE.

But we also see that developer interface usage scenarios are highly diverse. Developers aren't writing code seven days a week, twenty-plus days a month — they have many different tasks done on different platforms. Some need to write scripts, some do system maintenance, pipeline integration, or complete tasks on specific platforms. In the IDE, this is a fully encapsulated form — the agent can't be externalized or flexibly integrated.

So we needed a more flexible way for agents to be invoked and integrated as scripts or command-line tools. Additionally, different developers use different IDEs — Vim, JetBrains family, VS Code, etc. We can't assume everyone uses VS Code, and our IDE is VS Code-based, which naturally excludes some users.

But CLI can serve all developers, opening up a much broader user base. From these perspectives, we definitely had to release this form, because our goal is to serve users at larger scale.

As for how we compete with Claude Code — we don't see this as single-dimensional competition. From the model and cost perspective, Claude Code's context construction is relatively straightforward, but works well. We do things more finely. For example, using our own model dramatically reduces costs, while using external models would be very expensive, so we have to do more optimization in context assembly.

We have our own implementations in agent flexibility definitions, sub-agent design, and other aspects.

On the other hand, we emphasize more multi-scenario penetration and application-layer innovation. For example, I can assign tasks from my phone, or distribute and follow up on work in Slack or IM tools. This scenario-based capability meets real user needs. Model vendors typically don't do this kind of application-layer innovation, so we differentiate ourselves from them in positioning.

👦🏻 Koji

You mentioned "context engineering" several times just now. It sounds like Qoder has done a lot of work in this area. Could you elaborate? Are there any specific methodologies or optimization experiences you can share?

👦🏻 Shutong

To build excellent context engineering, you have to achieve "more, faster, better, cheaper" — that's the goal. At the same time, you need to think about the relationship between agents and tools — which tools to design, and what technical solutions to use to drive the model efficiently. Fundamentally, it's all about driving large language models to complete tasks.

We've done a lot of exploration, including relevance retrieval. Because you can't dump everything into the model every time — that would be too slow and too costly. So we need to find truly relevant content — should we use vector retrieval, text retrieval, or semantic retrieval? Each problem has its own optimal implementation.

At the same time, we need to decide whether to use an agent or sub-agent, which method to use for calling tools, how to aggregate context content, and how to piece together a reasonable context. Longer context isn't always better. We let the model interact within a reasonable context window, calling tools in loops, ultimately completing tasks efficiently and achieving that "more, faster, better, cheaper" effect.

We've also built a memory system. Memory is absolutely critical. When users interact with the model and use context engineering, they give implicit signals — they won't write it explicitly in prompts, but express it through feedback, like "this isn't what I wanted" or "I prefer this." We quickly abstract these preferences into rules, with some becoming system prompts and some becoming long-term memory.

This memory affects all subsequent interactions, letting the model gradually understand user preferences. This both controls context length and reduces costs, while making the model increasingly attuned to the user. Developers feel like "this tool gets me more and more," because it has learned my behavioral habits into its own behavioral constraints. Before I've even fully explained something, it already understands.

We've done extensive exploration and innovation in this area.

👦🏻 Koji

You mentioned Memory infrastructure earlier, plus sandboxing and Todo Lists. Are these all built in-house? Or do you also use open-source solutions?

👦🏻 Shutong

All built in-house. This also requires the team to have sufficiently deep understanding and accumulated expertise in this domain.

1024 Message: How Should Programmers Evolve in the AI Era?

👩🏻 Ronghui

I'd like to ask a somewhat personal question: If you could go back to when you first started working, knowing how much the world would change, how would you feel looking back at yourself then?

👦🏻 Shutong

I think every professional needs to be forward-looking, able to sense future changes and trends. Don't pay for past decisions; prepare for what's coming. I hope everyone can bravely take that step, make active choices rather than being passively pushed along. The world is actually very forgiving — have confidence, take action.

👩🏻 Ronghui

You've been a programmer for so long. In the process of building this product, did you ever feel like you were "revolutionizing yourself"?

👦🏻 Shutong

I don't see it as building a revolutionary tool, but rather exploring a development path for future programmers. We're thinking: What kind of tools will future developers, or broad developers, need? What kind of tools can create greater business value? These changes will happen regardless of whether we pursue them today — the way we work, organizational collaboration relationships, everything is changing.

We hope to approach this with a more future-oriented posture, one that understands developers better and grasps future organizational production relationships and collaboration methods, exploring a platform where developers can continuously grow. Not that "programmers won't be needed anymore, it'll all be tools doing the work" — I strongly disagree with that view. The future will definitely be a form of human-agent collaboration.

I've always believed that an excellent developer should stand on technology's shoulders, not become its slave. "Standing on technology's shoulders" means making technology work for you, creating greater productivity and business value. Seize the technological dividend, and you're a trailblazer; fail to seize it, and you may be eliminated.

So we want to democratize AI coding capabilities, lowering the barrier to entry. But if you can't actively embrace it, can't learn to harness AI, that will be a problem.

👩🏻 Ronghui

Then what do you think about "AI will replace programmers"?

👦🏻 Shutong

I'm relatively optimistic — I don't think AI will replace programmers. Programmers need to learn to harness AI, treat it as a giant, and stand on its shoulders to create business value. Such programmers will have brighter prospects.

Also, you can reference the Jevons paradox: when costs decrease, demand actually expands. AI lowers development costs, creative demand will explode, and we'll see a massive emergence of broad developers. They can do small innovations, serve specific groups, while professional programmers will do big innovations because they have stronger professional capabilities. So the number of programmers might actually increase.

The key is being able to leverage AI to unleash 5x, 10x productivity — such people will be more competitive. Those who can't do this may become ordinary programmers. Overall, I'm still quite optimistic.

👩🏻 Ronghui

What's your internal development process like now?

👦🏻 Shutong

Most of our team's daily development tasks are done using Qoder.

👦🏻 Koji

So you're using Qoder to build Qoder?

👦🏻 Shutong

Yes. We also have a clear requirement: what proportion of each person's code is AI-generated. This is essentially forcing everyone to reinvent themselves — not revolution, but self-reinvention.

👩🏻 Ronghui

When did this start?

👦🏻 Shutong

It started back in the Lingma era.

👦🏻 Koji

Then what do you think future engineers' core competencies will shift from "coding ability" to? Will they become more composite?

👦🏻 Shutong

We believe the definition of "developer" will become broader. Previously, everything was very siloed: backend, frontend, iOS, databases, DBAs, and so on.

But now these boundaries are being broken down. Backend people can do frontend, frontend people can do backend, because large language models have greatly leveled technical differences. Individual capabilities are amplified, boundaries are broken. After breaking the first layer of boundaries, there's a second layer: AI's code-writing ability has already surpassed humans, so competing with it on writing code is meaningless.

So people need to move up a level, with capabilities in demand insight, intent recognition, requirement articulation, overall design, result acceptance, product sense, and so on. These will become the core competencies of future developers. Every developer needs to grow into a composite talent.

👦🏻 Koji

If you were to give advice to two types of people — programmers on one hand, and first-year computer science students on the other — to help them develop better in the AI era, what would you say to each?

👦🏻 Shutong

For first-year computer science students, I have two pieces of advice:

First, fully embrace AI, explore the boundaries of what AI can do for you, and become someone who can harness AI.

Second, definitely study computer science fundamentals solidly.

Computer architecture hasn't undergone revolutionary change today — we still work within the John von Neumann architecture. Operating systems are still Linux, Windows, macOS. If you don't understand these underlying structures, you can't judge whether AI-generated results are good or bad, and you can't truly harness it. AI might "bullshit you."

At the same time, AI isn't omnipotent. For example, large language models can't create large language models themselves. An AI coding product can make an iOS app, but it can't build the iOS system, because that's too complex, too top-level, too scarce.

The parts that can't be replaced by AI are where the highest value-add lies. In the future, simple software might only be worth fifty cents — the simpler and more common the idea, the less valuable it becomes. Only by doing what AI can't do, by elevating your professionalism, can you maintain creativity and long-term competitiveness.

👩🏻 Ronghui

Then for engineers working at big tech companies, what core skills do they need for career development?

👦🏻 Shutong

For people in computer-related fields, this is actually a very good era. People used to always say "there aren't enough programmers," "development is delayed" — this situation may be broken in the future, because AI is breaking through the development bottleneck, which is a very good signal.

👦🏻 Koji

That suddenly sounds so happy, because project delays were really the most painful source before.

👦🏻 Shutong

Actually, I think this is precisely programmers' advantage. Over the past two to three decades, this industry has developed extremely fast, and programmers have almost all been continuously learning. So for them, learning something new, or mastering a skill deeply, isn't a difficult thing. This反而 becomes the biggest advantage today. I've always had confidence in programmers as a group — they will continue to create higher productivity and stronger competitiveness in the AI era.

Double Eleven Memories: A Top Architect's Two "Gaokao" Moments

👩🏻 Ronghui

What about you? Your experience is quite legendary — you worked on projects like Double Eleven architecture.

👦🏻 Koji

Nine consecutive years of Double Eleven without downtime was you holding it up in the back (laughs).

I used to be in charge of the mobile division at Jumei International Holding Limited. Back then, every big promotion meant downtime. One year on the eve of a major sale, several engineers even went to the server room to burn incense, praying the system wouldn't crash. Later this became a meme, and we'd joke about it every time.

So can you tell some stories from back then?

👦🏻 Shutong

Can't say it was just me and my team — actually the entire company invested enormous resources, and many excellent colleagues participated. When I joined, it was right during the phase where Double Eleven traffic was exploding. The situation was like this — compared to normal traffic, Double Eleven traffic would amplify roughly a hundredfold. Almost every system was on the edge of its limits.

The way we worked then was each person responsible for one system, or a few people responsible for one system, everyone like "railway police, each managing their own section." Normally this wasn't a big problem, because daily traffic had headroom; but once traffic exploded, this distributed architecture was prone to falling apart. You couldn't support hundredfold traffic with hundredfold costs — it wasn't economical, and technically unrealistic either.

So we began a comprehensive technical upgrade across middleware, stress testing, capacity management, automated operations, and elastic scaling. That was 2013. Our team proposed and implemented a concept — "full-link stress testing." We were the first team in the world to systematically develop this approach. Today, full-link stress testing has become standard equipment for every internet platform.

The goal of this technology was to make the entire system bottleneck-free. When traffic exceeded processing capacity, we wouldn't let it in; as long as traffic could enter, it would definitely be handled. All systems stayed at a consistent waterline — neither over-provisioned nor overloaded. The moment any link hit "full capacity," traffic would be blocked outside, prevented from crashing the system. Through this globally balanced architecture, we largely solved Singles Day's stability problem.

👦🏻 Koji

You make it sound effortless now, but I imagine the resistance you faced wasn't purely technical. After all, thousands of engineers, each with their own OKRs. Getting them to invest massive time retrofitting their systems for this solution, when it might have no direct connection to their performance reviews — how did you drive that forward?

👦🏻 Shutong

We had an extremely strong shared goal back then — Singles Day cannot go down. This was consensus across the board. The entire company, top to bottom, fought as one integrated unit. And one thing was particularly critical: Singles Day cannot be delayed. Software projects can slip their delivery dates, but Singles Day cannot. This constraint of "must fight on schedule" tilted all resources toward a single node.

Our team's role was more like a "driver" and "backstop." Resources we could coordinate, we coordinated; what we couldn't coordinate, we handled ourselves — because the timeline was fixed. We used various push methods in combination: top-down directives alongside bottom-up collaboration.

Additionally, there was one crucial foundational advantage — unified tech stack. Alibaba had achieved technical system unification very early. If it had been like some companies, with Python on one side, Go on another, plus Java and C++ mixed together, this would have been impossible to push through. Precisely because everyone was on the same tech stack, with much middleware being shared, we could achieve "one change affecting a wide swath." In the end, we completed the full-link stress testing system in just three months.

The sense of achievement from that project was extraordinarily strong. It not only safeguarded that year's Singles Day but also became a milestone for the entire industry. Nearly everyone who participated in it went on to tremendous growth.

👦🏻 Koji

Those years I was at Jumei International Holding Limited. Every night before our big promotions, nobody knew whether the system would crash after midnight. That feeling was like praying. I remember sitting in the war room, watching the transaction curve jump on screen, nobody daring to breathe. What was the mentality on your side? Were Alibaba engineers nervous too?

👦🏻 Shutong

Of course we were nervous (laughs). Our philosophy was "create Singles Day before Singles Day." That is, before the actual day arrived, we would run complete drills multiple times. These drills used real traffic, real user paths, real requests — the only differences were scale and timing.

But no matter how much you drill, you can never 100% replicate the real scene at that midnight moment. So there was always some anxiety. We typically ran three full-scale drills, say 500,000 transactions per second, pressuring from zero, exploding in one second. Each drill would expose new problems — some technical bottlenecks, some concurrency or capacity issues. We fixed them round by round, and by the third or fourth time, most problems had converged.

But even so, when the actual Singles Day arrived, we still didn't dare let our guard down. Because the actual traffic distribution, blockbuster products, marketing rhythm — all brought new uncertainties. So we required the system to have dynamic scheduling and self-healing capabilities.

From 2013 onward, there were basically no more major incidents, only minor fluctuations. At that scale, that was already a miracle.

👦🏻 Koji

Incredible.

👩🏻 Ronghui

What was your mood the moment Singles Day ended?

👦🏻 Shutong

Sometimes it was a bit about luck too.

👦🏻 Koji

Did you go to Lingyin Temple to pray?

👦🏻 Shutong

Yes yes yes, some did (laughs). It became a kind of tradition.

👩🏻 Ronghui

Going to Lingyin Temple to pray before Singles Day became a team ritual.

👦🏻 Shutong

Right. A kind of team building, also a way to release pressure. Everyone was so tense back then.

👦🏻 Koji

Was it the second that passed, your heart settled?

👦🏻 Shutong

Usually about ten minutes.

👩🏻 Ronghui

Was your mood the same every year? Were there times that felt especially different? Any urge to cry?

👦🏻 Shutong

The pressure was greater at first, then increasingly composed. Because our technical architecture evolved generation by generation — each generation faced new problems and had new opportunities. For example, after we solved stability, next came cost. We didn't want 50x traffic to cost 3x. So we later set a goal: Singles Day might have 50x traffic, but for the entire group, could we spend not one cent more?

👦🏻 Koji

Was this your proposal?

👦🏻 Shutong

No, the CTO proposed it. But we helped him achieve it. This also connects to why we pursued containerization and cloud-native transformation. We always had a mindset: constantly extract dividends from technology, let technology drive business, create value. Alibaba's technologists have always had this pursuit. When ideas like this were proposed, we never felt they were impossible.

Because the business has many segments: domestic, international, search, advertising, e-commerce, Fliggy, Ele.me, AutoNavi, UC, and so on, including models. Not every business participates in Singles Day, but none wants to be affected. Through new technologies like scheduling management elasticity and containers, we connected these resources, achieving time-division multiplexing, elastic scaling, and mixed deployment — both data and business types. With these technologies, we could complete large-scale cluster scaling in short timeframes, say completing resource switching within 10 to 20 minutes.

Cloud resources could also be reused, reused across business segments, reused across different time windows. Taking these to the extreme brought massive cost savings. These practices also became technical standards in the industry, driving the popularization of containerization and cloud-native technology domestically. Because everyone shares the same needs for efficiency, elasticity, and cost. Singles Day was just a microcosm.

👩🏻 Ronghui

Like the gaokao once a year. What you just described feels like mock exams to me. Simulate several times, constantly check what you don't know, then fix it. So from which year did you stop managing Singles Day?

👦🏻 Shutong

Later I started doing something else. Once we had pushed Alibaba's stability and cost to relatively high levels, we began considering how to monetize these technologies, to let capabilities overflow. Because these were universal industry needs, we began productizing to empower industry users — many internet companies, industrial internet users — using our productized technology to serve them. I worked on this for several years, responsible for some products. Then gradually I was no longer in charge of Singles Day.

👩🏻 Ronghui

Then how did you feel when Singles Day came around?

👦🏻 Koji

A relaxed shopping mood?

👦🏻 Shutong

Right.

👦🏻 Koji

Finally could buy freely, pile pressure onto the servers. Now it was finally my turn to add pressure, not bear it.

👦🏻 Shutong

Haha, right. But actually when we were on duty we also piled on pressure. We hoped for business growth too, and we were consumers ourselves. If the system was stable, we were buying too. If the system had problems, we'd stop buying and rush to fix it. If no problems, everyone kept buying — great deals too, had to grab some. The first 100 orders had discounts.

👩🏻 Ronghui

Then did you ever think, I've already done a project as big as Singles Day, what else do I need to do to get the same sense of achievement? What scale would it need to match?

👦🏻 Shutong

Can't think that way. For me, it's still about doing valuable things, things with social contribution. Technological progress, benefiting others — that's the source of a sense of value. Everyone needs a stage, and this stage isn't something you can have just by wanting it. It depends on the social environment and the platform you're on, and whether your capabilities are ready.

We made a judgment at the time that our technology for handling traffic was unrivaled globally. There couldn't be larger traffic; China's demographic dividend had peaked too. We had a system and methodology; not much more revolutionary stuff was needed. So we did a lot of technical standardization work, massive open-sourcing — middleware open source, cloud-native domain open source — while also beginning commercialization, hoping technology would create new business, opening new commercial landscapes through technology.

Essentially, it was letting technology create greater value, seeking a larger stage. Today, we believe AI is the biggest stage and amplifier, so we made this choice.

👩🏻 Ronghui

How do you feel about this choice two months later? It's been two months since launch.

👦🏻 Shutong

Completely correct. Utterly correct.

👦🏻 Koji

Utterly correct. Final question: In your view, what achievements in three years, five years, would make you especially satisfied? The picture you imagine, from programmer to user, what would it look like?

👦🏻 Shutong

Looking ahead to the future, if our three-year vision is realized, we hope to produce the most real software on a product like Qoder — software with commercial value, covering the most scenarios, generating more value through software.

From the perspective of how the world changes, the key is whether people believe AGI will arrive. My view is that I hope coding becomes a general capability, externalized through agents. As Sam Altman described, from conversation to reasoning, then to agent, innovation, organization.

I think within this three-year window, "organization" may happen. AI multi-agents can form linkages to accomplish grand, long-term, complex goals, calling various tools to interact with the real world. Coding can help it solve complex problems and bring determinism. Large language models don't have determinism when generating content, but code can bring determinism. In future management, production, and practice, coding is a necessary choice.

From the demand side, people's needs may be fully met, and many new business forms and entrepreneurial ventures will emerge. From the scenario side, for example, when Elon Musk lands on Mars, the houses on Mars definitely won't be built by astronauts but by AI. That will certainly be driven by large language models, agents, and robots together. I believe this day will come, and coding will play an important role.

👦🏻 Koji

Thank you Shutong for coming on "Crossing," and we hope Qoder achieves more. Welcome to come back for a review chat in six months, a year.

👦🏻 Shutong

Thank you.

References

[1] Qoder: https://qoder.com/