A Deep Dive into Cloud Coding Agents: How Users in China Can Choose Wisely

Silicon Valley's New Trick: Send AI Off to Write Code

Recently, a phrase has been trending in Silicon Valley's tech circles: sending AI "out" to write code for you. You just toss it a task, close your laptop, and walk away. It finishes the job in the cloud all by itself, then hands you back a Pull Request (PR) ready to merge. It sounds pretty sci-fi—and pretty satisfying.

The keyword behind all this is the much-hyped Cloud Coding Agent. But many people seriously misunderstand this concept—mistaking "being able to submit tasks from your phone" for "actually using a cloud Agent." These two things are not the same at all.

Technical Background: The Evolution of Cloud Coding Agents

A Cloud Coding Agent is an autonomous software engineering agent built on large language models (LLMs). Its technical lineage traces back to the "AI Agent" paradigm that emerged around 2023. Unlike early code completion tools exemplified by GitHub Copilot—which are essentially "smart autocomplete at the cursor," perceiving only the local context of the current file—Cloud Coding Agents introduce a closed-loop architecture of "plan-execute-verify": the model not only generates code but also invokes toolchains (filesystem read/write, terminal commands, testing frameworks, Git operations), iterating repeatedly within a sandbox environment until the task is complete.

The academic foundation of this paradigm is the ReAct (Reasoning + Acting) framework—where the model alternates in a loop between "reasoning" and "acting," with the results of each action fed back into the reasoning chain as new observations. This enables it to handle multi-step, stateful engineering tasks. The ReAct framework was proposed by researchers at Google and Princeton University in 2022. Its core insight: pure "Chain-of-Thought" reasoning lacks the ability to interact with the external world, while a pure sequence of actions lacks a reasoning-correction mechanism. Only by combining the two can a model work like a human engineer—"thinking while doing, verifying thoughts through action." In the Coding Agent context, this means the model can not only generate code snippets but also proactively read files, run test commands, parse error messages, and revise its approach accordingly—handling complex engineering tasks that require multiple rounds of interaction to converge, such as locating and fixing a bug spanning multiple modules, or progressively debugging through dependency conflicts until the environment stabilizes.

The evaluation standard is SWE-bench, a benchmark designed specifically to measure a model's ability to autonomously fix real GitHub Issues. Released by a Princeton University research team in 2023, this benchmark selected 2,294 verified "issue-fix commit" pairs from real GitHub repositories, requiring the model to autonomously locate and fix code defects based solely on the Issue description, without human hints. The difficulty lies in the fact that tasks involve real-world large codebases (such as Django and scikit-learn); the model must understand cross-file dependencies, reproduce complex runtime errors, and generate patches that pass the original test suites. Early models had a resolution rate below 5%; by 2025, mainstream products had surpassed 50%. This curve directly fueled the commercialization wave of the entire cloud Agent sector. The launch of Devin in 2024 pushed the concept into public view, followed by OpenAI Codex Cloud, Anthropic Claude Code, and GitHub Copilot Workspace, formally establishing the product form of "cloud hosting + asynchronous tasks."

Take GitHub's Copilot Coding Agent as an example. The official documentation puts it plainly: you toss it an issue or a single sentence, and it works within an isolated cloud environment—reading the codebase, making a plan, modifying branches, running tests, and finally submitting a PR, all on its own. There are quite a few players in this space—Devin, Codex Cloud, the Claude Code web version, Copilot Coding Agent, Cursor's cloud Agent, and more.

You might not have noticed a fundamental shift: the unit of work has changed. AI is no longer completing your code line by line; instead, it's "one task in exchange for one mergeable PR." Your role has also shifted from "writing code" to "reviewing PRs."

Why is "reviewing PRs" a reasonable work model?

The Pull Request is the core mechanism of modern software engineering collaboration, originating from Git's distributed version control system. After a developer completes changes on an independent branch, they submit a "merge request" to the main branch, triggering quality gates such as Code Review and automated testing (CI/CD). This mechanism naturally decouples "writing code" from "reviewing code," fitting asynchronous collaboration scenarios. The core value of a PR isn't just "checking whether the code is correct"—it's that it builds a traceable record of decisions: each merge comes with discussions, rationale for changes, and review comments, serving as an important vehicle for accumulating team knowledge.

Cloud Coding Agents leverage precisely this existing engineering norm: the Agent completes coding in the cloud and submits a PR, while the human engineer is reduced to the "final reviewer." It's worth noting that "reviewing PRs" doesn't mean the workload plummets—reviewers must judge whether changes align with the architectural intent and whether they introduce hidden performance or security risks, and these judgments rely precisely on deep domain experience. This means an engineer's core value shifts from code production to requirement decomposition, architectural judgment, and quality gatekeeping—which aligns closely, in principle, with the "code review culture" long advocated in software engineering. It's not a disruption, but an acceleration.

Breaking Down Three Axes: Don't Be Fooled by the Concept

The so-called Cloud Coding Agent actually mashes three different things into one lump. To see clearly what it's really selling, you need to break it down into three independent axes.

Axis One: Where It Runs

Does the work run on your own machine, or in someone else's hosted cloud sandbox? This is the most critical distinction.

Technical Implementation of Cloud Sandboxes

The core infrastructure of cloud Agents is the "disposable isolated sandbox," typically based on containerization (Docker/OCI) or micro-VMs (such as AWS Firecracker, Google gVisor). The difference between the two lies in the trade-off between isolation strength and startup speed: Docker containers share the host kernel—starting extremely fast but with a thinner isolation boundary; micro-VMs like Firecracker provide an independent kernel for each task, offering a harder security boundary while compressing startup time to the millisecond range. Firecracker was originally developed by AWS for Lambda and Fargate scenarios and later open-sourced. Its core design philosophy is to "provide VM-level security isolation while retaining container-level lightweight startup"—which happens to be the ideal foundation for large-scale Agent task scheduling.

When each task starts, the platform clones a brand-new execution environment containing a complete OS userspace, dependency package manager, and codebase snapshot; once the task ends, the environment is destroyed without a trace. This solves the most frustrating "environment pollution" problem in local development—you can freely install experimental dependencies and run destructive test scripts in the sandbox without affecting the host machine. Platforms like GitHub Codespaces and E2B have turned this capability into an API, allowing Cloud Coding Agent products to spin up dozens of parallel sandboxes on demand. This is precisely the core barrier that local solutions struggle to replicate in terms of operational convenience.

Axis Two: Who's Watching

Are you watching it constantly and guiding it step by step, or do you toss it out to run through a full task unattended?

Axis Three: Where It's Initiated

Are you operating at your desktop, or launching tasks remotely from your phone, WeChat, or Feishu?

Once you separate these three axes, it becomes clear: the so-called Cloud Coding Agent is essentially a bundle of "cloud hosting + asynchronous task dispatch." And "submitting tasks from your phone" only touches the third axis.

The Biggest Misconception: Phone Task Submission ≠ Cloud Agent

Here we must clarify the most common misconception: many people think that being able to fling a task from their phone means they're using a cloud Agent. This is wrong.

Submitting tasks from your phone is now an industry-wide standard. Codex has a mobile client, Claude has a mobile client, and domestic tools like Tongyi Lingma and Tencent CodeBuddy can all dispatch tasks from the phone. Zhipu's new Z.ai coding tool goes even further—you can simply @ it in a WeChat or Feishu group, and a one-sentence task starts running.

In other words, "being able to control it from your phone, or even via WeChat or Feishu" is by no means a unique trick of cloud Agents—it's a standard feature across all tools, and domestic products are actually more down-to-earth in this regard.

What cloud Agents truly monopolize and others struggle to replicate, from start to finish, is just one thing: hosted disposable isolated sandboxes + zero-ops parallel capability.

Four Hard Barriers Facing Users in China

Honestly, these overseas players are basically unfriendly to users in China, mainly stuck on the following points:

• Network barrier: GitHub's cloud VMs are overseas. Devin, Codex, and the like are essentially unreachable without a VPN.
• Payment barrier: Registration and payment mostly require a foreign-currency credit card.
• Regional blocking: The cloud versions of the Claude series are region-blocked for mainland China. Even with a VPN it's unstable, and paying doesn't guarantee access. This isn't an account-ban risk—it's a hard block at the access layer.
• Compliance barrier (the most fatal): Private repository code has to be uploaded entirely to overseas cloud sandboxes, and domestic enterprises basically can't get past this hurdle.

Why is "uploading code overseas" a compliance red line?

For domestic enterprises, uploading private code repositories to overseas cloud services involves risks across multiple compliance dimensions: the Data Security Law (effective 2021) and the Cybersecurity Law have explicit security assessment requirements for the cross-border transfer of "important data"; the Measures for Security Assessment of Data Cross-Border Transfer, issued by the Cyberspace Administration of China, further specify the types and scale thresholds of data requiring declaration and assessment. Heavily regulated industries such as finance, healthcare, and government affairs also have their own data localization rules—for example, the Guidelines on Data Governance for Banking Financial Institutions explicitly require that core data must not leave the country. Even for internet companies, the source code of core algorithms and business logic is usually considered a highly sensitive trade secret; once leaked or disclosed by an overseas cloud provider under local law, it would bring immeasurable intellectual property losses. By contrast, running Agents locally keeps code entirely within the intranet throughout. For enterprise users, this compliance advantage is almost decisive—far more critical than "whether you can submit tasks from your phone."

Not Being Able to Use It Doesn't Mean You Miss Out: Local Alternatives

The good news: the core benefits you want are either already served up by domestic tools, or can be replicated on your own machine. It all depends on which one you actually want:

• Just want to submit tasks from phone/WeChat: Zhipu Z.ai supports @-mention task submission via WeChat and Feishu, Tencent CodeBuddy can dispatch tasks via WeCom, and Tongyi Lingma also has a mobile client. If you want fully autonomous control, you can SSH from your phone into your own machine and add Tailscale to set up a private network.

Tailscale: Connect Your Dev Machine from Your Phone Anytime

Tailscale is a modern networking tool built on the WireGuard protocol, adopting a "zero-trust network" architecture. WireGuard is a next-generation VPN protocol natively supported by the Linux kernel, known for its minimal code footprint (around 4,000 lines, compared to OpenVPN's hundreds of thousands), excellent performance, and modern cryptography—its cipher suite fixedly uses Curve25519 key exchange and ChaCha20-Poly1305 data encryption, eliminating configuration errors caused by the complexity of cryptographic negotiation in traditional VPNs. Unlike traditional VPNs that require a central server to relay traffic, Tailscale completes device authentication and key distribution via its Coordination Server, after which traffic is encrypted and transmitted directly between devices (P2P), with extremely low latency and no bandwidth bottleneck at the central node.

Its core value is "letting your phone and any device securely access your dev machine at home or work"—no public IP needed, no port forwarding, and even devices hidden behind NAT can punch through for a direct connection, with extremely low configuration overhead. This makes "SSH from your phone to a local dev machine to trigger Agent tasks" truly practical: when out and about, connect to a high-performance workstation via Tailscale's private network from your phone to get a "remote task dispatch" experience similar to cloud Agents, while keeping code entirely within the local network and reducing compliance risk to zero. For teams wanting full self-hosting, Headscale is an open-source alternative to Tailscale's Coordination Server that can be privately deployed, completely eliminating dependence on third-party services.

• Want asynchronous task dispatch: Use GitHub Actions in combination with domestic tools, triggered by issues; or use Claude Code's headless mode.
• Want automatic PR submission after changes: Just set up a resident dispatch Agent yourself, such as frameworks like OpenClaw or Hermes.
• Want parallelism + isolation: Use Git Worktree to open multiple branches and multiple terminal windows for manual parallelism, and use Docker as an isolated sandbox.

Git Worktree: The Underrated Local Parallelism Gem

Git Worktree is a native feature introduced in Git version 2.5 (2015) that allows checking out multiple working directories from the same repository simultaneously, with each directory corresponding to an independent branch, fully isolated and non-interfering. Compared to "cloning multiple copies of the repository," Worktrees share the same .git object store, consuming less disk space, and all branch states are managed within a single Git view, making branch switching and merging more atomic. More importantly, multiple Worktrees share the same Git history objects, meaning large repositories don't need to repeatedly consume several GB of space for full clones—especially useful on laptops with limited local disk.

When replicating cloud parallelism locally, developers can create a Worktree for each concurrent task (git worktree add ../feature-branch-1 -b feature-1), and use tmux (a terminal multiplexer) or multiple terminal windows to run independent AI Agent processes. Each process modifies code in its own directory without affecting the others, and ultimately submits its own PR. Going further, different Worktree directories can be mapped to different Docker container mount points, giving each concurrent Agent task a fully isolated filesystem view while sharing the host's compute resources; combined with the git worktree prune command, working directories corresponding to merged branches can be automatically cleaned up to keep the disk tidy. This local solution can even outperform some cloud products in security and controllability, at the cost of having to bear the operational overhead of environment configuration and resource scheduling yourself.

Only when you truly can't be bothered to set up an environment yourself and need to run dozens of parallel tasks at once is it worth paying to go to the cloud.

Which Tasks Are Suitable to Fling to a Cloud Agent

Remember one core principle: the cloud isn't here to replace local—it's here to fill in the gaps. It's only worth it when you pick the right scenario.

Four Types of Tasks Suitable for Cloud Dispatch

1. Batches of unrelated small tasks: revising docs, batch-adding tests, generating dependencies, unifying code formatting—running five in parallel is much faster than one by one.
2. Tasks with clear boundaries and definite acceptance criteria: one sentence can clearly state what's wanted and what counts as done.
3. Tasks requiring installing dirty dependencies or running destructive experiments: use a disposable cloud sandbox, and don't dirty your local environment.
4. Fragmented time away from the computer: commuting, meetings, or before bed—fling a task from your phone and review the PR when you're back.

Four Types of Tasks Better Kept Local

1. Exploratory work with vague requirements that needs back-and-forth discussion while working.
2. Tasks that require constant watching and readiness to interrupt and correct course at any time.
3. Private logic involving sensitive code that can't be transmitted externally.
4. Rapid iteration on small projects—you're sitting right at the computer, and making a round trip through the cloud is just a hassle.

In one sentence: for work that's about process and control, do it yourself; for work that only needs results, has clear boundaries, and can be parallelized, fling it out. Just as you wouldn't watch your assistant do every little thing, but the core logic still needs your personal oversight.

Conclusion: Don't Be Intimidated by "Futuristic" Buzzwords

This wave of cloud task dispatch isn't without value—used in the right scenarios, it can genuinely help you clear a backlog of tasks. But it's been hyped as "the silver bullet for fully automated AI development," when the only thing it truly monopolizes is that small piece of "managing your environment and parallel operations for you."

Phone-based task submission is already standard for domestic products, and you can set up asynchrony and parallelism yourself. So don't be intimidated by this futuristic-sounding buzzword: if you can use overseas services and genuinely need to run dozens of parallel tasks, choose overseas services or domestic alternatives on demand; for individual developers seeking convenience, local plus a phone entry point is enough. Tune it to the right scenario, don't spend money carelessly—that's the rational way to use it.

Key Takeaways