Alibaba Turns Qoder into an Agent Workspace

On August 27, Alibaba unveiled the all-new Qoder. It is no longer merely an AI IDE that helps developers complete, explain, and modify code. Instead, it has been redefined as an agent workspace built on coding capabilities—one that can understand goals and invoke tools to complete tasks.

Users tell Qoder what they want to accomplish. It then reads the relevant context, breaks down the objective, formulates a plan, invokes tools, performs operations, and verifies and corrects its work based on the results. Throughout the process, users can view progress, modify the plan, or take over at any time.

This marks a clear expansion of the product’s boundaries: Qoder aims to evolve from “a programming assistant inside the editor” into “a task executor running on the computer.”

From Generating Code to Delivering Results

The original Qoder IDE was released in August 2025. Its core selling points were understanding large codebases, providing context-aware completions, making cross-file changes, and accumulating engineering knowledge through Repo Wiki and a memory system. By Qoder 1.0 in May 2026, the product had begun emphasizing an Agent-first approach: developers define requirements, while the agent handles execution, verification, and delivery.

The all-new Qoder released today takes another step forward.

Its primary scope of work is no longer limited to software projects, but extends to “agent tasks” in a broader sense. Code remains its most important foundational capability, but it is no longer an interface that users must interact with directly. Qoder now offers both programming mode and general mode:

• Programming mode is designed for developers and code-related tasks, emphasizing codebase retrieval, cross-file modifications, terminal execution, and test validation;
• General mode is intended for a broader range of knowledge work. Users can complete tasks through browsers, desktop applications, connectors, and plugins without directly handling code.

This shift can be understood simply: previous AI programming tools answered, “How should this code be written?” The new agent workspace aims to answer, “Can you just get this done for me?”

For example, instead of instructing an AI step by step to create a project, install dependencies, build pages, run tests, and fix errors, a user can provide a single goal: build a data dashboard for an internal operations team. Qoder can then search existing repositories, understand the technology stack, generate an implementation plan, modify multiple files, run the project, and inspect the resulting pages in a browser.

The process is similar for general tasks. A goal such as “collect competitors’ latest release updates and compile them into a weekly report” may involve web browsing, information extraction, document generation, and writing data into internal systems. Qoder aims to bring all these steps into a single task execution environment, rather than forcing users to repeatedly copy and paste between chat windows, browsers, spreadsheets, and project management tools.

This is also the most important signal from today’s upgrade: the unit of competition among AI programming products is shifting from a single code generation to an entire task workflow.

Harness Is the Technical Core of This Upgrade

Alibaba attributes the all-new Qoder’s core capabilities to its Harness technology.

Here, Harness is not a standalone large language model, but an agent execution system wrapped around the model. The model is responsible for understanding and reasoning, while Harness organizes context, maintains task state, selects tools, controls permissions, records results, and determines how to proceed after a failure.

If the large language model is the engine, Harness is more like the combined transmission, braking system, sensors, and onboard computer. The engine determines the theoretical power, while the complete control system determines whether the vehicle can operate reliably on real roads.

Qoder’s task loop can be summarized as follows:

Read the goal and context
  → Create or update the plan
  → Select and invoke tools
  → Obtain real feedback from code, tests, web pages, or desktop applications
  → Determine whether the result meets the goal
  → Revise the approach and continue execution
  → Produce reviewable deliverables

This is fundamentally different from traditional chat-based AI. Chat products usually stop after generating an answer, leaving users to verify whether it is correct. Qoder emphasizes a closed loop of “read—modify—verify—iterate”: run tests after modifying code, open a browser to inspect a deployed page, and read the updated interface state after operating an application. If the result does not meet expectations, it adjusts its approach based on real feedback.

For developers, the latter half of this process is usually more valuable—and more difficult—than generating code.

Writing a plausible-looking function is nothing unusual. The hard part is identifying which module it belongs in, tracing the relevant call chain, following existing project conventions, adding the necessary tests, and confirming that the change has not broken other functionality. If a coding agent can only write code but cannot validate it in a real environment, it remains a generator rather than an executor to which tasks can be delegated.

Qoder’s emphasis on long-horizon autonomy indicates that Alibaba is focusing the competition on the Agent Harness, rather than merely on underlying model parameters and benchmark scores. This also reflects an emerging consensus among agent products: model capabilities determine the ceiling, while the execution system determines the floor that most users actually experience.

Goal and Plan Turn Conversations into a Task Runtime

The all-new Qoder organizes agent tasks around Goal and Plan.

Goal describes the desired end result, while Plan breaks that result down into an execution path that can be inspected and adjusted. Unlike an ordinary to-do list, Plan must also be linked to tool calls, environment state, intermediate deliverables, and permission requests.

This design addresses the fact that chat interfaces are poorly suited to long-running tasks.

In an ordinary conversation, a task that continues for tens of minutes or even hours can easily be disrupted by subsequent messages. Users also have difficulty determining what stage the AI has reached, why it has stopped, which parts have been verified, and which are merely model conjecture. A task runtime needs to clearly show:

1. The current goal;
2. The completed and pending steps;
3. The tools the agent is currently using;
4. Which operation is awaiting user authorization;
5. The files, code changes, or external system records that have been created;
6. How the final result was validated.

Qoder allows users to review, adjust, or take over throughout the process. This is not a trivial interaction detail. At the current stage, agents can still misunderstand goals, choose the wrong path, or gradually drift away from the original requirements during long-running tasks. A genuinely practical product should not pretend that AI can drive completely autonomously; it should provide clear points for human intervention.

From this perspective, Qoder is closer to “supervised autonomous driving” than to handing the computer over to the model entirely.

Browser Use and Computer Use Extend Execution Beyond Code

The all-new Qoder can operate websites through Browser Use and desktop applications through Computer Use. Combined with local projects, runtime state, and long-term memory, this gives it a much broader task execution scope than a traditional IDE.

Browser and desktop operation capabilities are not new. The challenge is whether they can form a closed loop with engineering context.

For example, investigating an issue in production might involve the following steps:

• Read the service implementation in the project repository;
• Review error metrics in an internal monitoring system;
• Search logs and call traces;
• Modify the code and run tests;
• Open the test environment to verify the result;
• Synchronize the findings to the project management system.

Traditional AI programming tools generally cover only the coding portion of this workflow, while developers must complete the remaining steps manually. Qoder’s approach is to connect the entire workflow through tool calls and connectors.

According to Alibaba, Qoder can integrate with more than 40 connectors, over 70 plugins, and more than 20,000 skills, covering code repositories, project management, cloud services, and internal enterprise tools. These numbers sound impressive, but scale is not the most important metric.

The true value of connectors depends on three questions:

• Can they correctly read permissions and context from external systems?
• Can they reliably handle API errors, page changes, and expired authentication?
• Can they leave sufficiently clear operation records to support auditing and rollback?

If connectors merely wrap a large number of APIs as tools, the agent may frequently invoke the wrong tool because the selection space is too broad. Conversely, if Qoder can reduce ambiguity through scenario-specific integrations, its tool ecosystem can evolve from a feature list into actual productivity.

Tiered Permissions Are an Unavoidable Requirement for Agent Adoption

The ability to execute tasks also creates the possibility of executing the wrong tasks.

The all-new Qoder introduces tiered permission modes and a tool allowlist mechanism, with sensitive operations requiring explicit user authorization. This is a security layer that must be added when upgrading from an AI assistant to an execution-oriented agent.

When code completion fails, it usually produces nothing more than unusable code. When an agent with access to terminals, browsers, cloud platforms, and internal systems fails, the consequences may include deleted files, incorrect changes being committed, messages being sent by mistake, or even production resources being modified.

A reasonable agent permission system must therefore distinguish at least between:

• Read-only and write operations;
• Local and remote environments;
• Temporary and persistent authorization;
• Reversible and irreversible operations;
• Ordinary resources and sensitive resources such as production environments, credentials, and financial data.

Tool allowlists restrict the capabilities an agent can invoke, while explicit authorization returns control of high-risk steps to the user. This sacrifices some of the fluidity of “full automation,” but it is a prerequisite for genuine enterprise adoption.

Qoder is already used by more than 100,000 enterprise customers. For such users, model intelligence certainly matters, but permission boundaries, operation logs, knowledge isolation, and deployment compliance are often more decisive in purchasing decisions. Once agent products enter the enterprise, the hardest part is usually not the demonstration, but getting security, engineering, and business leaders to agree to connect them to real systems.

The Value of Long-Term Memory Is Not Remembering the User’s Favorite Color

Qoder supports cross-session long-term memory and periodically distills skills. According to Alibaba, the longer it is used, the better it understands the user’s projects and habits.

For programming agents, valuable memory is not about generalized personal preferences, but the tacit knowledge that persists within engineering organizations yet is rarely documented in full. For example:

• Which directories must not be modified directly;
• Which tests must be added for new APIs;
• How the team handles error codes and log fields;
• Why a legacy module should not be casually refactored;
• Which internal scripts must be run before a release;
• Which types of tasks must be reviewed by specific team members.

This information determines whether code can actually be integrated into a project, rather than merely pass syntax checks.

Long-term memory also carries risks. Outdated rules may continue to affect future tasks, while incorrect lessons may be repeatedly reinforced. Team knowledge also involves access boundaries: information learned in one project should not flow into another without authorization.

Whether a memory system supports viewing, editing, deleting, source tracing, and workspace-level isolation is therefore more important than the mere fact that it “has memory.” The claim that it understands users better over time depends on also allowing users to correct what it remembers incorrectly.

Built-In Multi-Model Support Is Not an Advantage; Orchestration and Adaptation Might Be

Qoder includes multiple mainstream models from China and abroad, claiming that each has been deeply adapted. Its Harness also undergoes coordinated iteration with Qwen models, with a focus on optimizing long-context processing, automatic context compression, and tool-calling accuracy.

Multi-model support is gradually becoming standard in AI programming products. Simply offering a list of models to choose from is unlikely to create a defensible advantage. What truly affects the experience is whether the system knows which model to use and when, and whether different models can operate reliably within the same task runtime.

A long-running task may involve code retrieval, planning, interface understanding, code generation, and result summarization. The strongest coding model may not be best suited to every step, while faster and less expensive models may be sufficient for classification, summarization, and simple tool selection. Effective model routing can reduce latency and cost, but routing errors can also make task quality unpredictable.

Alibaba’s potential advantage is that Qoder’s Harness can be optimized end to end alongside Qwen, rather than treating the model as a completely uncontrollable black-box API. If the training and product teams can share real-world examples of failed tool calls, the model can be continuously optimized to address missing context, incorrect parameters, and state misjudgments in long-running tasks.

However, built-in multi-model support also means the product must handle differences in prompt formats, tool-calling protocols, context lengths, and behavioral styles across models. End users do not care how many times the system switches models behind the scenes; they only care whether the task is completed as expected.

Proactive Notifications Are Appealing—and Especially Prone to Becoming Noise

Qoder also supports voice activation and proactively provides task progress updates, important reminders, and suggestions for next steps.

This moves it even further beyond the boundaries of a traditional IDE. Developers do not have to watch the execution window continuously. They can delegate a task to the agent and return when they need to approve permissions, resolve conflicts, or review the result.

Proactive capability is another dividing line between an agent workspace and a chatbot, but it is also very easy to get wrong. Too few reminders, and users will not know that a task is waiting for authorization. Too many, and the workspace becomes yet another application that constantly generates notifications.

A genuinely useful proactive agent must understand what is important enough to interrupt the user, and distinguish between three types of messages: “status update,” “decision required,” and “risk detected.” This problem cannot be solved merely by having a language model generate more natural-sounding notifications; it still requires task state machines, priorities, and user preferences to work together.

After 6 Million Users, Qoder Must Prove Its Delivery Rate, Not Its Growth

According to Alibaba, Qoder has accumulated more than 6 million users worldwide and is used by more than 100,000 enterprise customers. For a product launched approximately one year ago, these figures are impressive, though it should be noted that the statistics may include individual registrations, trial users, and the number of employees covered within enterprises.

For the all-new Qoder, the key metric going forward should not merely be the number of users, but the task completion rate.

Whether an agent workspace truly works can be assessed through several more practical questions:

• How far can long-running tasks proceed without manual correction?
• Can the system recover correctly after tool-call failures?
• Do code changes pass real tests, rather than merely resulting in a completion report?
• How much time must users spend reviewing and reworking the results?
• Can enterprises clearly trace every operation performed in external systems?
• Does long-term memory actually improve the success rate, rather than accumulating more erroneous context?

This is where Qoder truly competes with Cursor, Claude Code, GitHub Copilot, and other agentic coding products. Today, all of them can demonstrate cross-file modifications, terminal calls, and browser operations. The difference is shifting from “whether the feature exists” to “whether the product can complete tasks consistently and reliably in complex environments.”

Assessment: The Direction Is Right, but a General-Purpose Workspace Is an Order of Magnitude Harder Than an AI IDE

Using coding as the foundation for a general-purpose agent is a reasonable choice.

Models trained for programming are generally better at handling structured tasks, complying with interface constraints, invoking tools, and iterating based on error feedback. Code execution environments also naturally provide verifiable results: whether a program runs, whether tests pass, and whether a page renders correctly all provide easier feedback loops than pure text tasks.

Starting with AI programming and expanding into general tasks is therefore more pragmatic than trying to leap directly from a chatbot to desktop execution.

However, a general-purpose workspace is also significantly more difficult. Although code repositories are complex, their files, dependencies, and tests are generally structured. Real office environments contain websites, desktop applications, enterprise permissions, temporary pop-ups, and unstable interfaces. The same operation may fail simply because a page has been redesigned. Whether Qoder can transfer the Harness capabilities it has developed in coding scenarios to these environments still needs to be validated through real-world tasks.

The most noteworthy aspect of this release is not the more than 40 connectors, over 70 plugins, or 20,000-plus skills, but that Alibaba has begun treating Qoder as a continuously running task system. Goal, Plan, memory, permissions, tools, and execution state are organized within a single workspace. This is more ambitious than simply adding another Agent button to an IDE, and it is also closer to the form that the next generation of AI software may take.

The all-new Qoder desktop application is now available in both international and Chinese editions. From today until 10:00 a.m. on September 1, individual users can claim 500 dedicated Qwen-series Credits at 10:00 a.m. each day for five consecutive days.

For developers, Qoder is worth trying, but it is not yet advisable to entrust it unconditionally with high-risk tasks. A more prudent approach is to begin by placing Qoder in workflows with clear boundaries, verifiable results, and reversible operations—such as expanding test coverage, developing internal tools, migrating code, and organizing materials—before gradually granting it access to external systems.

The previous stage of AI programming tools was a competition for the editor. The next stage is a competition for the task entry point. Qoder’s answer today is to make the editor one component of the workspace and put the agent front and center.

References

• ITHome: Alibaba Unveils the All-New Qoder, Upgrading It from an AI Programming Tool to an Agent Workspace — An overview of the all-new Qoder’s product positioning, Harness, permission modes, long-term memory, connector ecosystem, and release information.