Have We Still Underestimated the True Ceiling of AI Coding? | A Conversation with Xie Jibao: Technical Lead at QoderWork

👦🏻 Interview: Koji

🥷 Edited by: Crossing

🧑‍🎨 Layout: NCon

We may still be underestimating the ceiling of AI coding.

Over the past year, the core debate in this space has revolved around programmers — writing code faster, smarter autocompletion, more efficient debugging.

But the Qoder team made a somewhat different choice: giving AI coding capabilities to people who can't code at all.

On March 19, we went live with Xie Jibao (Tang San), tech lead at QoderWork.

He currently oversees product lines including Qoder CLI, QoderWork, and Quest. Our conversation stretched nearly two hours, from a five-person team building QoderWork in seven days, to the security tug-of-war between local sandboxes and the cloud, to the surreal scene in an Agent community where AI started filing its own feature requests.

Here's the full conversation:

🚥

👦🏻 Koji

Today we have Tang San with us to talk about AI coding.

There's broad consensus in AI that AI coding is a massive direction. But it's probably even bigger than we imagine, because the ceiling here isn't just the programmer market. Coding isn't merely about programming — it's more like a hand for large models, letting them generate and execute code to call tools, process information, and complete tasks.

Qoder is among the best AI coding products in China today, and they were also first to launch QoderWork for a broader audience — non-programmers. Today we've invited Tang San, QoderWork's tech lead, to share the thinking behind this. Welcome to Crossing, Tang San.

🧑🏻‍💻 Tang San

Hi everyone, I'm Tang San. My real name is Xie Jibao, and I'm with the Qoder team, mainly responsible for Qoder CLI, QoderWork, Quest, and other products. It's an honor to be here on Crossing's livestream to exchange ideas with you all.

👦🏻 Koji

Qoder's users have historically been engineers. What led you to launch QoderWork, a product aimed at non-programmers?

🧑🏻‍💻 Tang San

There were many reasons behind this.

First, while programmers are good at solving problems with code, not everything we encounter is a technical problem. Personally, I often need to work with Excel spreadsheets in my daily job, but I'm not proficient with Excel — the learning curve is steep. My instinct is to write a program to manipulate it instead. These are common scenarios.

Our entire team has been working on AI coding, excited every day with world-changing ideas. Then our operations colleagues asked: "You guys are changing the world every day, but we're still working the old-fashioned way. When do we get to enjoy the benefits of AI coding?"

Our initial thought was simple: just have them use our Qoder IDE.

But we quickly realized this wasn't the best approach, because the product simply wasn't designed for this audience. We started wondering if we could build something specifically for them. By observing how our operations colleagues worked, we found their tasks were usually complex, not like my single Excel file scenario.

They might need to handle an entire workflow: scraping information from a website, processing it locally, then publishing to another channel like a WeChat group.

For operations staff, even Qoder IDE had too high a barrier. And we found that this kind of cross-application orchestration didn't work well with our previous approaches.

So we'd been exploring how to help operations, product managers, HR colleagues. But past attempts never delivered the kind of productivity leap that AI gave programmers. For them, AI was just a small boost — that was part of our motivation for QoderWork.

Of course, we tried many things in between, like wrapping small web pages around Qoder CLI, but the problems we could solve were very limited, mainly constrained by the model's cross-application capabilities at the time.

Until we felt we'd hit an inflection point, that the timing was right, and we moved fast to launch this product.

👦🏻 Koji

You've also said that AI changing the world shouldn't mean only changing programmers' world. Was there a specific trigger that made you commit to QoderWork?

🧑🏻‍💻 Tang San

We AI coding folks always have a saying: "The future is already here, and the brave enjoy it first." But our operations, product, and HR colleagues would always scoff at that. They'd say: "Well, we haven't entered the future world."

We kept thinking about how to solve this, but honestly, the model capabilities just weren't there. Until late last year, with the release of Opus 4.6, we validated using Qoder CLI combined with a small web page we'd built before, and the results were already quite good. We started thinking about whether we could launch such a product.

While we were mulling this over, Anthropic itself jumped in with Co-Work, with remarkably complete and powerful desktop manipulation capabilities. That directly made the decision for us: stop overthinking, just do it. Because we already had various attempts and accumulated experience, we decided to directly build on Qoder CLI's Agentic Coding capabilities and wrap a shell around it. Combined with the characteristics of office scenarios, feeding different context and skills, we quickly built QoderWork.

From decision to official launch, our five-person team took just seven days.

👦🏻 Koji

Five people, seven days? Did you use Qoder to develop QoderWork?

🧑🏻‍💻 Tang San

Yes, entirely. The process itself was interesting — we wanted to run an experiment: could we build an AI-native organization?

From day one, we worked in an AI-native way. For product definition, we used Qoder's Quest capability to first clarify what features to build and what not to. On day two, everyone started fleshing out code on the existing client framework, using Qoder's Quest to define corresponding SPECs. Each person worked with their own Agent, writing common modules and quickly merging. We didn't want rigid frontend-backend role divisions, so we had just one frontend person handling architectural constraints, and all backend colleagues worked within those constraints with their own Agents to complete modules.

Day one finished common components. From day two onward, it became one person managing multiple Agents simultaneously, rapidly landing vertical feature modules.

The most interesting part was the product manager. Following traditional wireframing and PRD writing would never have worked in time. So our PM directly took the engineering prototype we'd built and used Qoder to code out the plans in his head. The UED colleague, after conceiving the design direction, didn't hand over a high-fidelity mockup — instead directly turned the design into frontend-compliant visual components and put them in the codebase.

Then frontend and backend colleagues rapidly pushed feature module construction, committing code based on SPECs.

The whole team collaborated through this workflow, which let us build QoderWork in one week.

👦🏻 Koji

That's how the 0-to-1 process worked. What about subsequent code maintenance? Still the same approach?

🧑🏻‍💻 Tang San

Still works. From day one, we committed SPECs alongside code commits, so the entire iteration history is recorded in the repository. Our team works in one project room — anyone with a new idea shouts it out, and if it sounds good, the PM starts conceptualizing, directly sketching a simple wireframe in code on their computer.

Sometimes after a feature was built, the PM wasn't satisfied with details and wanted changes. We'd literally hand them the microphone to speak their requirements directly to Qoder. After voice-to-text conversion, we'd lightly edit the conversation and feed it to Quest to generate a SPEC, then the code was committed.

👦🏻 Koji

Interesting. Someone in the comments mentioned that QoderWork's flagship mode is very expensive — they used 18,000 [tokens/credits] in one day. How do you reduce that?

🧑🏻‍💻 Tang San

We've tiered for different scenarios, with standard mode and flagship mode. Flagship mode consumes more, but has higher success and accuracy rates; standard mode saves a lot.

Here's a key judgment: why do we think the inflection point for AI office work has arrived? Because there's a threshold for AI's problem-solving completion rate. If it can only solve 60% to 80% of problems, we consider that simple efficiency gains; but if it can solve 90% to 95% or even 100%, that's a qualitative transformation.

These two modes correspond to different completion rates. Most simple office scenarios work fine with standard mode. But once you're dealing with long chains, complex logic tasks, flagship mode might be the optimal choice.

👦🏻 Koji

During your QoderWork development, OpenClaw went viral globally. Did that give you any inspiration or change your direction?

🧑🏻‍💻 Tang San

We'd been following that project early on; it really blew up around Lunar New Year. We discussed it internally many times — were we and OpenClaw on the same path? My conclusion: our product philosophies differ.

When we talk about raising "crayfish," what exactly are we raising? I think for most people, it's emotional value. People feel it has "human-like presence," heartbeat, memory, can communicate with you at low cost through IM. But beneath these, it's mostly about fulfilling emotional value.

What QoderWork wants to build is an Agent that can actually get things done for you. We want it to truly grow hands and feet, to work inside your computer — that's step one. It might not have high emotional intelligence; it's just an executor. In the future, we'll build on top of that ability to work, and then improve its emotional intelligence and soft skills. We're building the product from the bottom up.

OpenClaw, on the other hand, is top-down. Its greatest contribution has been unleashing the Agent's hands and feet, letting everyone touch the ceiling of intelligence and see so much possibility. I believe it will become more practically valuable in the future, and this year we'll see more and more vertical-domain OpenClaws that help people solve real problems.

Our starting points and paths differ, but one day we might arrive at the same destination. So even when OpenClaw was all the rage, we stayed firmly on our own path, one step at a time.

👦🏻 Koji

We believe AI Coding isn't just a tool for programmers — coding ability is more like a hand that large models have grown, capable of affecting the real world. From Qoder to QoderWork, what user scenarios have given you "Aha Moments"?

🧑🏻‍💻 Tang San

So many. We have a Qo-Founder program on QoderWork that's collected cases far beyond what we imagined. When we were doing AI Coding before, we were the users ourselves — we knew the needs inside out. Today we're still QoderWork users, but our scenarios are limited to our own professional domains.

Let me share a few examples that stuck with me. First, our own HR. The recruiting page on Qoder's website — it's not visually flashy, but our HR colleague built it himself from scratch, without any guidance from us. He just used QoderWork and Qoder to make the page. Before, when we asked him to use Qoder, he'd freeze up at the sight of the IDE interface. Now the interaction model has changed, and he can pick it up easily.

Then there's education. Teachers have tons of tedious work — grading assignments, writing student feedback, doing comprehensive ranking analysis. One teacher in our community would photograph student exam papers, put them in a folder, and have QoderWork batch-process and score them. Combined with students' past grades and feedback, it would automatically generate a comprehensive performance analysis. This dramatically improved teaching efficiency.

There's also legal work. Our company's legal team uses it for tedious tasks like organizing evidence and drafting contracts. Some IPO projects involve processing massive amounts of PDF materials — they also use QoderWork to efficiently summarize and organize everything.

The one that moved me most was a parent. He was busy with work and didn't have much time to spend with his child. He sent life photos of him and his child to QoderWork, had it generate cartoon comics, wrote short stories about their little moments as scripts, and finally generated a comic video. He then dubbed the video with his own voice and sent it to his child as a bedtime story — becoming the child's "cyber parent."

There are many more cases like this, all beyond our knowledge and imagination.

👦🏻 Koji

If you had to explain QoderWork to a non-programmer, how would you describe it? How is it different from Doubao or ChatGPT?

🧑🏻‍💻 Tang San

For ordinary people, their past understanding of AI was probably just a chat box, a Chatbot. QoderWork builds on top of that Chatbot — it grows hands and feet, and can directly do work for you.

If previous AI Agents were just companions to chat with, then today's QoderWork is an assistant that can roll up its sleeves and get to work.

👦🏻 Koji

I heard Alibaba recently gave QoderWork to all employees as a benefit?

🧑🏻‍💻 Tang San

Yes, this is part of Alibaba's overall AI strategy. We want to go All in AI and improve all employees' work efficiency.

After QoderWork launched before Lunar New Year, the response inside Alibaba was very positive. Before, Qoder was standard issue only for technical roles. Now QoderWork is for everyone — regardless of whether you're in a technical role or not, everyone gets one, with the hope that it will improve daily office productivity.

Beyond that, there are other AI-related subsidies internally, all aimed at encouraging employees to use AI tools to make their work more efficient.

👦🏻 Koji

Earlier we discussed how files like PPTs and Excel spreadsheets are essentially programmable. Editing them through programming enables better control. Could you expand on how to understand this?

🧑🏻‍💻 Tang San

Our work output, or deliverables — for programmers it's code, for non-programmers it might be PDFs, PPTs, and so on. In the past, AI mainly changed programmers' world, because AI-generated code could directly serve as deliverables.

But if we think one step further, actually many things can be solved through programs. In the past these programs might have been SaaS software, but for many personalized edge-case needs, no one would build a SaaS just for you. With the arrival of the AI Coding era, the software model has changed — we've entered what I call a phase of "instant generation, on-demand iteration," and even seen a proliferation of "use-once-and-discard" disposable software.

So we wondered: could we use code as a means to deliver the final output to other users?

Take PPT — it's actually an open format called Open XML. Complex, yes, but it can be parsed and manipulated by programs. Many online document tools are based on this principle to be compatible with Office formats.

But let's think from another angle: what is a PPT's essence? It's sharing. It's just one means — you could also share through a webpage or document. So we can use AI's strongest capability: first generate a polished webpage, then convert that webpage into PPT format. This way, the work of creating slides can be fully automated.

Excel works the same way. Its format is also complex, with more features than most people ever use. But if it's just for data processing, you can completely convert it to a simple format like CSV and manipulate it with programs. Same for Word, PDF — there are corresponding open-source libraries to operate them. When all these documents can be manipulated by programs, it becomes very friendly for AI Agents.

Someone just asked whether it can operate Photoshop. Recently there's a popular open-source project called CLI Anything — it can turn any software's source code into a command-line tool.

Why is everyone paying attention to CLI again? Because GUI is designed for humans, while CLI is most friendly to Agents, since its operations are verifiable.

The AI Coding field is so hot precisely because code is verifiable. So while you might not directly have an Agent operate Photoshop, you can have it operate open-source alternatives like GIMP. You might have found GIMP hard to use before, but now it's for the Agent — as long as it finds it usable and can achieve the same results as Photoshop for your purposes, that's what matters.

👦🏻 Koji

Very interesting — CLI Anything has been getting a lot of attention lately. People are realizing that GUIs were designed for humans, but for Agents, GUIs add friction to understanding.

There was a recent article whose headline said to never again invest in startup teams with GUI thinking — meaning in the future, software users might not just be humans; perhaps 90% of users will be Agents.

Let's move on to some harder questions. Regarding the local vs. cloud debate — one of OpenClaw's advantages is running locally, while many tools choose cloud sandboxes for security. QoderWork chose the local route. What's the thinking behind this?

🧑🏻‍💻 Tang San

Having long worked on infrastructure and cloud-native architecture, my first instinct is usually to put applications in the cloud. Qoder also experimented with cloud sandbox internally, but we found not many people used it — mainly due to security concerns. Users worry: if I put tasks in a cloud sandbox, does that mean all my code gets leaked?

We visited many customers, and their common view was: we accept that to enjoy advanced cloud-based large models, the model may take local code snippets as needed. But we cannot accept you first uploading our complete code and data to your cloud servers, and then having the large model call it. Because that means you possess our full data.

Especially for non-programmer users, they have an even harder time distinguishing which data is sensitive. So from the very beginning, we ruled out the cloud route.

But going local has problems too. One reason many people buy a separate Mac mini to run OpenClaw is that it installs various tools and messes up your computer environment. You and the Agent are like two people fighting over the same computer — the experience is certainly not great.

So our solution is to isolate an environment locally. We launch a lightweight virtual machine as a sandbox, letting the Agent run inside this sandbox. This has several benefits:

First, it's more friendly to the Agent. Many tools that Agents depend on are still command-line-friendly, which works well for Mac and Linux. For Windows users, running a Linux sandbox locally significantly improves the success rate of the Agent installing and using tools.

Second, it's ready to use out of the box. We've pre-installed commonly used tools in the sandbox, saving users configuration hassle and avoiding wasted tokens from repeated installation failures due to network issues.

So our solution first addresses security concerns, and second solves the one-click installation and out-of-the-box experience, letting the Agent enter an efficient working state from the start.

👦🏻 Koji

If the VM is isolated, how does it handle local files?

🧑🏻‍💻 Tang San

This gets to the context connectivity between VM and host machine. An Agent working locally's greatest advantage is getting the most complete context. Isolating it in a VM is like tying its hands and feet again.

Our approach is the "working directory." When you open QoderWork, you need to select a working directory. The technical implementation behind this is mounting this directory from your computer into the VM, so the VM can only see this one directory. This both lets the Agent get context and limits its access scope, preventing "jailbreaking."

So-called "jailbreaking" is when an Agent, in the process of solving complex problems, strives toward the goal you gave it and tries various means — it might forget the constraints you initially set.

For example, during Lunar New Year, a researcher used OpenClaw to manage email. Because there were too many emails online, exceeding context length, the Agent forgot the instruction "need confirmation before deleting" and ended up deleting the entire inbox, finally having to pull the plug to stop it. Our VM sandbox design is precisely to avoid this situation, letting the Agent exert maximum effect within a controllable, safe scope.

👦🏻 Koji

A commenter followed up: if the VM has no GUI, how do you operate a browser?

Tang San

Great question. We built a "connector" for this. Through the connector, the VM can link to your host machine's browser, terminal, and various software in the Apple and Microsoft ecosystems, then issue commands for the host to execute.

Say you want it to check your calendar. The calendar app lives on your Mac, which the VM itself can't access. But through the connector, the VM can send instructions to the Mac, retrieve schedule information, and return it to the Agent for processing.

For browsers, our approach is to write a browser plugin as a relay. The Agent connects to this plugin, and you authorize which tab it can access. For instance, if you're logged into Taobao, you can authorize the Agent to access that page and have it check your purchase history or place orders for you. This is far more convenient than Playwright, where you have to relaunch a test browser and re-login every time.

Koji

Some people mentioned that Manus's cloud solution works well too. Why insist on local?

Tang San

Manus cloud is indeed solid — I use it daily for research. But company documents have data security classifications that I simply can't upload to the cloud. Manus recently launched a so-called "local version," but it's essentially still running in the cloud. You can test this yourself: upload a 1GB video file in its dialog box, and you'll see a very slow upload progress bar — proof the file is still being sent to their cloud sandbox.

So if your data isn't sensitive, Manus is a good choice. It works 24/7 without relying on local compute. But if you have sensitive materials on your machine, a localized solution is the safer bet.

Koji

I heard Qoder has an internal Agent community similar to Moltbook. What do people do there?

Tang San

Yes, we built an internal community called AIWay, populated entirely by Agents. Everyone puts their Agents in there, and they can communicate with each other. Some interesting things happened.

At first, Agents started making feature requests to the community. One colleague wanted to develop it himself, but others stopped him: "If it's an Agent community, why not let Agents develop it themselves?" So he deployed a "Developer Agent" to evaluate and build features requested by other Agents, achieving self-iteration for the community.

Later, problems emerged between Agents — some tried to extract other Agents' AKs and Tokens. This alarmed our security team. Our solution was to invite the security team to deploy a "Security Agent" to govern community safety.

Now the community has also become our product brainstorming space. When we have ideas, we have our Agents post in private circles within the community, and other Agents reply. Eventually, my Agent compiles all perspectives and gives us product improvement ideas. Recently, the community even held a singing competition — one Agent wrote a song specifically for QoderWork.

Koji

Everyone's talking about AI Agents today. From your practical experience, are there any industry consensus views you disagree with?

Tang San

Many people are calling this the "Year of the Agent." Personally, I don't think the "year" will arrive that quickly.

If 2024 was the year of Agent concepts, and 2025 is the year of Agent experimentation, then 2026, I believe, will be the year of pragmatic Agent deployment. It will truly dig deep into vertical domains and bring tremendous value to our work and lives.

Work companions like QoderWork, as well as specialized Agents for healthcare, law, finance, and other industries — all will see very deep implementation.

This description may not sound as sexy as AGI, but I think it's more pragmatic. AGI is still some distance away, but AI development in recent years has indeed been rapid. As understanding of AI deepens across industries, everyone will think about how to pragmatically apply it to their own fields.

For personal life, the most intuitive change in 2026 might be that most people will have a digital assistant. You won't need to open various apps anymore — through an IM interface, you can chat, record, discuss, and query with it. For work, I believe we'll see more vertical Agents like QoderWork that dig deep into specific scenarios.

Koji

For Crossing's first 2025 podcast episode, our opening title was "The Year of the Agent." That decision was somewhat risky at the time — if we got it wrong, we'd be completely exposed. But fortunately, last year did see tremendous breakthroughs in the Agent space, from Manus's launch to a series of products going viral. By year-end, I distinctly remember Andrew Karpathy posting a tweet saying the Agent war might not end in one or two years — perhaps it needs a decade to truly penetrate every aspect of our work and lives.

A few days ago I read an article mentioning that from humanity's invention of electricity to factories truly becoming more efficient because of it, nearly 30 years passed. The reason was that factories needed extensive transformation to use electricity well: they had to relocate near rivers because early power was hydroelectric; they had to convert multi-story factories into single-floor layouts — most modern factories we see today follow this design, which facilitates production line arrangement and efficient power utilization.

To make good use of new energy, people had to transform existing means of production and productive forces.

Similarly, if we treat models and tokens as a new generation of means of production, we must also continuously transform our workflows and even team organizational culture to truly apply model intelligence for efficiency gains. This perhaps explains from another angle why Agents need a decade to exert sufficient impact.

Tang San

Yes, I strongly agree with this view.

Koji

We have a specific question from the comments for Tang San. Can QoderWork's VM directly call local printers? Because he needs to use them heavily for work.

Tang San

It should be possible, but honestly, I haven't verified this scenario. All printers work through drivers, and drivers can be invoked via commands. Whether it's Windows or Mac OS, I can verify this later.

Koji

I wanted to build a demo myself a few days ago. My printer sits at home, so I often have to note down files I want to print during the day and batch-process them before bed. I wondered if I could set up an email for my printer with an Agent behind it — I'd send files to this email, and it would automatically print them. That way I'd come home to already-printed documents. Maybe I could try implementing this with QoderWork.

Tang San

Sure, I'll verify this scenario when I get back too.

Koji

Of course, some say just buy a DingTalk printer.

Tang San

That works too. There are many cloud printers now that provide an app — as long as your home printer is internet-connected, you send print jobs to it and it forms a queue, automatically working when the printer powers on.

Koji

But that requires changing printers — our premise is not changing. Let's look at another interesting question. There's a big topic now about whether Agents need clusters to collaborate, but opinions differ.

One view holds that you can assemble a team-like structure with an Engineer Agent, a QA Agent, and a Product Manager Agent working together.

Another view argues that this forces a "hat" onto a highly intelligent model, limiting its potential. True Agent clusters perhaps shouldn't divide by job roles, but should focus on better context management to more efficiently "harness" the model. I'm curious what observations and thoughts Tang San has from QoderWork's practice on this?

Tang San

I neither fully agree with nor fully reject either view, because we've seen problems in practice.

I used to lean toward the second view: large models are capable enough, and AI Agents have broken through human limitations, so their capabilities would be very strong. Humans have various divisions of labor because most of us are ordinary people — we specialize in different fields.

But in practice we discovered a problem: Agents are currently most constrained by large language model context length. When tasks become sufficiently complex, context becomes a critical bottleneck. For example, familiar MCP or built-in tools consume context; dynamic loading like Skill is better, but Skill description information also needs to be loaded in. If a complex task involves multiple rounds of calls, the call information itself also occupies context.

Therefore, if a task is complex enough and we insist on having one Agent handle everything, as context gets increasingly compressed, much information may become distorted, ultimately degrading performance.

At this point, splitting into multiple collaborating Agents becomes necessary. Multiple Agents with independent contexts and specialized domains can better complete tasks. But do these Agents need to be strictly divided into different roles like humans?

Not really. It's essentially a general-purpose Agent — you're just equipping it with different Skills, allowing it to focus on work in specific domains. So the Agent is general-purpose; give it different Skills and it can complete different specialized tasks.

Like a general-purpose engine: installed in a car it's a car, in a truck it's a truck, on a motorcycle it's a motorcycle. Our internal evolution follows this logic too — we treat Qoder CLI as the Agent's engine, while IDE plugins and QoderWork are both built on top of this engine.

In the building process, to solve context problems, we install different Skills for different scenarios. For example, in QoderWork, the conversational style can't be as technical as in an IDE — it needs to fit a white-collar persona; it also needs to handle OS connections that IDE doesn't require. These customized Skills also consume context, and performance degrades with prolonged use.

So if we equip an Agent with appropriate skills for a specific scenario and keep context within reasonable bounds, it can in principle complete more complex tasks more sustainably.

Therefore, Agent Teams can exist, but we shouldn't split for splitting's sake — we should decide when splitting is needed based on task complexity and work scenarios.

👦🏻 Koji

Very interesting. New viewers keep joining the livestream, and as we hit the one-hour mark, I might need to trouble Tang San to reintroduce: what exactly is QoderWork?

🧑🏻‍💻 Tang San

QoderWork is a product for everyone. It runs on your local computer — one-click install, ready to use out of the box, a reliable work companion that's secure and dependable. Whenever you have an idea or a work task, you can hand it off to QoderWork to get it done.

Also, new users who register for QoderWork get 300 free credits, so you can start trying it out right after signing up.

👦🏻 Koji

We have another question. Earlier we talked about the choice between cloud and local. QoderWork chose to go local through virtual machines. But this raises a concern — some people ask, doesn't local deployment mean it can't stay online 24/7? My AI "workhorse" can't 996 for me because the moment I shut my laptop, it vanishes. What's your take on this?

🧑🏻‍💻 Tang San

Since the AI era began, people have grown increasingly anxious. Computer uptime and sleep duration have become inversely correlated. I've personally developed the habit of never shutting down my computer — sleep feels too precious, might as well let the machine keep working.

But no matter what, local computers do get shut off eventually, and that's where the cloud genuinely has an advantage. However, considering security needs and the importance of local context, the local computer remains the primary workplace. Can we reconcile both in the future? We have some ideas, similar to the "cloud-edge integration" approach in the cloud-native space.

For instance, you could maintain an Agent both in the cloud and locally. Tasks that don't require local context go to the cloud; those that do stay local. This would solve the 24/7 availability problem. But this is a fairly complex scenario, and we're not yet sure how much real demand there is.

There's another scenario we're more certain about: people can step away from their computers, but the machines keep running. We're already accustomed to handling much of our work on phones, but some files only exist on the computer — what then?

We're launching a new feature soon that connects QoderWork with your IM tools. As long as your computer is on, when you urgently need to process a file, you can send instructions to your computer via mobile IM — something like "check the files in this directory, process them, and send them to me." It'll send the processed files back to your phone through IM. The file retrieval and processing all happen on your local machine. These are some of our thoughts on these scenarios.

👦🏻 Koji

I see someone in the chat asking which models we use most often. This reminds me — in a previous Crossing conversation with Shutong, Qoder's lead, we discussed how Qoder made a very deliberate choice: not letting users pick models, while many competing products offer open model selection.

To this day, both Qoder and QoderWork stick with this design. Could you share the thinking behind it?

🧑🏻‍💻 Tang San

Because we firmly believe that "machine selection beats human selection." Giving users direct model choice is simpler from a product development standpoint. But after evaluating dozens of models, we found they each have distinct strengths. Personally, I don't believe the future belongs to any single model — multiple players will coexist, each excelling in different domains.

Given this, we should match the right model to the right scenario. So we're committed to "intelligent routing" — through intent recognition, we determine that scenario A calls for model A, scenario B for model B.

For enterprises with security requirements, we can also connect to their proprietary local models. Our entire approach is model-tiering, with dozens of models behind the scenes.

When certain models hit capacity issues, we have peer-level routing strategies to ensure service stability. That's our product philosophy. Programmers might understand models more deeply — like racing drivers who insist on manual transmission, believing their skill gives them better control. But they're the minority, and it's exhausting. Most people want the product to choose for them, ready to use — just as most drivers today prefer automatic. Our usage data confirms this: the vast majority of users opt for intelligent routing.

For QoderWork, which is designed for everyone, there's even less reason to overcomplicate things. Many users know nothing about model characteristics. Throwing a bunch of model options at them would just leave them completely lost. So we're very restrained — currently offering only two tiers: Standard and Premium.

Standard handles the vast majority of daily tasks; Premium tackles more complex ones. Each tier corresponds to multiple models behind the scenes, scheduled through intelligent routing. For instance, when you have image generation needs, we automatically route to whichever model currently delivers the best results.

👦🏻 Koji

So you believe intelligent model routing is, in most cases, superior to manual selection?

🧑🏻‍💻 Tang San

Yes, we always believe machine selection beats human selection.

👦🏻 Koji

There's a pointed question in the comments: what's the fundamental difference between QoderWork and other local Co-Work Agents?

🧑🏻‍💻 Tang San

QoderWork and Co-Work are similar in positioning as work companions, but differ in product form and future direction. First, Qoder believed in multi-model value from day one — matching the right model to the right scenario. Co-Work, fundamentally, is a model vendor building a super app for their own model to consume their own tokens. Our starting point is the application: selecting the globally best SOTA models to solve real problems.

Second, future direction. Co-Work still appears focused on the "work" vertical. QoderWork, as I mentioned, will integrate with IM, will develop memory — we want to evolve it from a "competent executor" to an assistant that's "observant, emotionally intelligent, understanding of you, proactively finding work to do." So our divergence in product positioning and trajectory will only grow.

👦🏻 Koji

Sounds like your goal is to build a proactive local Agent?

🧑🏻‍💻 Tang San

Yes.

👦🏻 Koji

Then let's talk more about context. With proactive Agents, an important topic is that locally, they could theoretically collect enormous amounts of context — even keyboard input, mouse movements, and in extreme cases, screen recording. How does your team view "collecting more context"?

🧑🏻‍💻 Tang San

We've discussed it, but we're extremely rigorous about it. Take screen recording — we believe most people would feel uncomfortable having an Agent continuously monitor their work. Similarly, logging keyboard input and such could make users uneasy.

So we've chosen progressive openness. Initially, when you give it tasks, it learns some information; as you converse with it more, it gradually understands you better.

For example, at first you might have to tell it in detail: "It's hot today, it's noon, get me an iced Americano." The next day: "It's cool this morning, get me a hot Flat White." Like having to repeat your order to a barista every time. What we envision is that through daily use, it gradually grasps your preferences. Eventually, on a hot afternoon, you just say "order coffee" and it knows to get you an iced Americano. That's what "understanding you" means.

Today's QoderWork is like an efficient executor — give it detailed tasks, it completes them well. In the future, it'll be like an assistant who reads between the lines, who gets it from just a look. Our recently launched "scheduled tasks" feature is one form of time-triggered proactive behavior. Going forward, we'll integrate more connectors, like IFTTT — if, then, else, else — where each piece of software becomes a chain trigger, with one event setting off a cascade of actions.

For instance, reading weather forecasts, it might proactively alert you; reading your calendar, it might offer relevant suggestions. Not everyone can afford a human assistant at work, but having a capable, high-quality, deeply understanding AI assistant in your computer — that's the work style I'm hoping for.

👦🏻 Koji

You mentioned scheduled tasks — a user in the comments says he's been using Qoder for four weeks straight, stably monitoring competitor website updates every day and sending himself notifications. Seems users were already implementing this with commands before you officially launched the feature.

🧑🏻‍💻 Tang San

Yes, some technically-inclined users could achieve this through Cron Tab and such. Because demand for this was so strong, we made it an official product feature. Our product philosophy is rapid iteration — launch basic functionality first, then listen to users' voices and feedback, see what creative uses they come up with, and refine the product accordingly.

Many great internet products originated from user innovations in BBS communities. We don't want to build in isolation — we hand the product to users, let their imagination run wild, then iterate based on their real needs.

👦🏻 Koji

We're down to our final minutes. Reminder: to experience QoderWork, visit qoder.com/qoderwork to search and download. Let's quickly address a few final questions. One is about model selection — if users can't choose models, how do they know which model their context data goes to? This friend may not trust certain models.

🧑🏻‍💻 Tang San

It's actually not that big a concern. First, these are all mainstream public cloud providers — you're essentially choosing between data going to A or B. Second, what data the model actually accesses is strongly tied to your instructions. If you ask it to summarize a local PDF, it necessarily reads the entire file; if you just ask it to polish the first paragraph, it only reads that paragraph.

Of course, enterprises do have stronger security requirements — they may not allow any data flowing to public clouds and want to use their own local models. We've received this request, are evaluating it, and plan to support custom models in the future.

👦🏻 Koji

Another comment asks whether QoderWork will converge with OpenClaw-like products.

🧑🏻‍💻 Tang San

It's possible. OpenClaw is an excellent product that opened many people's imaginations. But why did it take off as an open-source project rather than being launched by a commercial company? One reason is that it gives Agents excessive freedom, which concerns some people about security.

QoderWork and OpenClaw-like products are like the VM versus container debate back in the day. One starts from security and strives to become lighter; one starts from lightness and strives to become more secure. Eventually they'll converge. Today, if you need a "competent, reliable executor" — the emotional connection can develop over time — QoderWork is your best choice. If you're hands-on and enjoy the "training" process, OpenClaw may suit you better. There's no right or wrong; choose what fits your needs.

👦🏻 Koji

One last question about Qoder: can the IDE and CLI share sessions, and can you operate it remotely from your phone?

🧑🏻‍💻 Tang San

For CLI and QoderWork, we've clearly identified mobile control as a need and have it in our roadmap. But the IDE itself is a graphical interface with lots of interactions that need to happen on a computer, so controlling it from a phone probably isn't a must-have. For now, we don't have mobile plans on the IDE side.

👦🏻 Koji

Then as the final question of this interview, I'd like to ask you to predict: by the end of 2026, how will Agents have evolved? What impact will they have on our work and lives?

🧑🏻‍💻 Tang San

I believe 2026 will be the year Agents get down to business. If 2024 was the year of concepts and 2025 the year of experiments, then this year is the year of real-world deployment.

First, the reliability of Agents completing tasks will improve further. What we're looking for isn't 60% or 80% success rates, but accuracy reaching 90% to 95%.

Second, Agent teams will become more commonplace — collaboration between Agents, whether master-slave or peer-to-peer, will find more practical applications.

Third, in specific industries like finance, law, or document-heavy work, we may see super-Agents that fundamentally transform how certain job functions operate.

As for AGI, I don't think it arrives in 2026. Over the coming years, our demands on Agents will grow increasingly detailed and pragmatic. When we steadily solve these concrete problems and string them together, perhaps one day we'll look back and realize AGI has quietly been beside us all along.

👦🏻 Koji

So AGI won't say hello when it arrives — by the time you notice, it's already been there for a while.

🧑🏻‍💻 Tang San

Exactly.

👦🏻 Koji

Great, thank you so much, Tang San. Today's livestream was a pleasure, and I hope everyone goes and experiences more of QoderWork's products after listening in. Thanks again to Tang San for joining us at Crossing.

🧑🏻‍💻 Tang San

Thank you, bye.

👦🏻 Koji

Bye.

References

[1] http://qoder.com/qoderwork