Every time the coding assistant reads a file, it has to ask for confirmation. DeepSeek's new approach defaults to observation-only mode, cutting redundant scheduling decisions by about 30%.

[ Author: He Yuzhi | Editor: Lu Yue ]

Many engineers who have brought AI into their daily R&D work share a similar frustrating experience: they finish typing a prompt, get up to grab a glass of water, and come back to find the process in the terminal stuck halfway, with the cursor sitting alone on the screen waiting for them to manually press Enter.

For a while now, promotional messaging for all kinds of coding assistants has emphasized how fast they generate: type a line of natural language, and the large model instantly spits out hundreds of lines of code, with all test cases in the terminal turning green. But in real software teams, this seemingly impressive instant feedback is turning into a high-frequency tug-of-war over energy.

Every time the agent reads a file, changes a line of configuration, or runs a command, it pops up to ask for permission. You just finished explaining the business context in a group chat, then switch to the code review tool to submit changes, and have to carry the whole backstory over again.

Once a task involves cross-module troubleshooting or dependency refactoring, the conversation window quickly overflows with dozens of rounds of context, and one wrong step sends it answering off-topic.

The one who brought this awkwardness into the open is an architecture proposal from a top domestic technical team.

On the evening of October 31, 2026, the DeepSeek Harness team published a long technical article on its official WeChat account titled "Super-agent Design Exploration: Toward a More Autonomous Agent System," systematically laying out a research prototype design for software engineering.

According to the official long article, the team did not spend much space at the opening hyping how fast the large model can write runnable code, but instead stated a core principle up front: occupy as little of people's attention as possible and deliver as much value as possible.

This long technical article directly points out the most awkward bottleneck in AI programming today: as the underlying model's single-point generation capability grows stronger, the bottleneck limiting output scale has long since changed—what really holds teams back is the attention limit of human developers.

Forcing the agent to reply instantly in the chat box and ask for permission at every step often just wears people out. Throwing it into the background and turning it into a distributed system that can schedule itself and isolate its components from one another is the path AI should take to truly integrate into software engineering.

>_ section 01

The faster AI writes code, the busier humans become

In existing coding agent architectures, the single-session serial mode has never been cheap—what it consumes is human energy.

Most mainstream coding assistants today, whether command-line tools or desktop plugins, are basically built on a single think-and-act loop.

This tiny dialog box is stuffed with too many chores: it has to understand human language on one hand, reach out to run command-line operations and read/write files on the other, and also withstand the ultra-long context of dozens of rounds of tool calls.

According to the observations of the DeepSeek Harness team in the long article, a human engineer in actual work can usually keep only three to five active sessions in deep memory and effectively follow up on them at the same time.

Once that number is exceeded, the human brain cannot maintain the continuity of multiple contexts and is forced to jump back and forth between different chat windows.

A more realistic problem than model capability lies in collaboration gaps. In real R&D scenarios, communication is never single-point. A product manager may propose a plan adjustment in an instant messaging group, an architect may give two lines of comments in code review, and the CI pipeline may report a build failure in the background.

Under a single-session architecture, these three pieces of information are scattered across different platforms, and the agents are isolated from one another. The only synchronization link is the exhausted human developer in the middle.

This design reduces developers to cheap context porters and approval tools for high-frequency click confirmation. The model appears to reply instantly on screen, but in reality it pushes the most tedious multitasking state management onto humans.

When most of an engineer's energy is spent verifying what the model intended to execute a few minutes ago, so-called efficiency becomes a hidden drain on energy.

>_ section 02

Completely separate the "dispatcher" from the "doers"

Since a monolithic loop cannot handle complex tasks, the most intuitive engineering solution is to borrow the divide-and-conquer idea from modern operating systems.

The prototype solution broken down in the long article has at its core splitting the system into two layers: a resident Router at the front end responsible for overall coordination, and multiple mutually independent Workers mounted at the back end. The two are clearly decoupled in responsibilities, permissions, and model resource allocation.

The Router, resident in group chats or repository backends, acts as the system's scheduling hub. It is only responsible for reading incoming event messages, assessing intent, and generating tickets with strict permission boundaries, which the team calls "Tickets with authorization letters."

The Router itself does not even need to be equipped with low-level high-risk execution tools, and in terms of resource allocation it only needs to run a lightweight model. It does not touch specific code changes and does not participate in long logical reasoning; its purpose is to keep the global interaction channel clear and avoid deadlock due to some complex task.

The one that really tackles the hard problems is the Worker automatically started in the background after receiving a ticket. Each Worker has an independent execution session and isolated workspace.

As long as the environment allows, the system automatically assigns the Worker an independent temporary Git worktree, letting it tinker freely in a clean copy of the code—changing configuration and running tests without affecting the main branch.

This physical isolation directly cuts off cross-contamination between long tasks.

Developing a new API and troubleshooting an online error can be advanced in parallel in the background by different Workers. Even if one crashes due to an infinite loop in the code, it will not pollute the main branch, let alone confuse the Router's main control context.

The rough and heavy work is absorbed in the background by isolated child nodes, while externally the dispatcher uniformly reports back to humans. Only then does multitasking in parallel have reliable engineering support.

>_ section 03

Don't let all information harass the brain

Besides separating execution from scheduling, how to remain restrained amid the flood of complex messages is key to whether an agent can truly settle into a team.

In a daily collaboration environment, group chat discussions, code commit pipelines, and automated test failures are generating information all the time. If the agent behaves like an eager new intern who craves attention and jumps in on every message, the attention of the entire R&D team will instantly be drowned by notifications.

In its design, DeepSeek introduced event filtering and pass-through mechanisms similar to traditional network protocols. When messages pile up, the system first uses a few lines of lightweight code rules to block small talk and noise at the door. Only real events that hit the whitelist are handed to the large model for intent understanding.

For potential tasks inferred from discussions, the system sets an extremely restrained default level in permission control. DeepSeek puts a tight leash on proactive task claiming: by default, only observation mode is enabled.

Even if the large model sees at a glance that the code is flawed and should be refactored, it only dares to quietly note in the local log that this task could have been taken—without a human giving the nod, it would never dare claim a ticket and change code on its own.

Another highly practical engineering design is subscription pass-through. When a Worker claims a Pull Request, the system automatically establishes a many-to-many event mapping at the underlying level.

All subsequent review comments on that PR are delivered directly by the underlying system to the Worker process responsible for the task, and no longer need to go through the Router for a second round of relay.

According to simulated test data released by the DeepSeek Harness team, after eliminating repeated interruptions to the main controller, the number of redundant decisions at the scheduling hub dropped by about 30%, and the computing resources needed to read the cache were reduced by more than one third.

Only by compressing the communication link into the context of the actual work can the system remain quiet amid multi-party collaboration.

>_ section 04

Only if the math works can it join the team

When a technical solution moves from a standalone demo to all-day team residency, the final test is never how smart a single conversation is, but only the robustness and operating efficiency of the entire system.

In the blind imagination of many teams, the more versatile the agent, the better—ideally with infinite memory and autonomously thinking in the background without rest. But in the real compute ledger, such castles in the air can collapse at any time due to a brief network interruption or a process crash.

What DeepSeek demonstrates in the long article is a typical disenchanted engineering perspective. To cope with the unavoidable freezes and exceptions during long-running operation, the system completely separates state storage from model computation.

The task's authorization status, ticket progress, and interaction history are all persisted to a local lightweight database, while the execution environment is fully containerized.

Even if the local host restarts or the session process times out, the system can be reawakened through an external independent watchdog mechanism, read the last snapshot from the database, and continue forward without requiring humans to type out the whole backstory again.

In a simulated scheduling experiment with about 300 messages and 20 work requests, this divide-and-conquer system showed a clear engineering advantage in task completion time. When facing high-concurrency message bursts, the tail latency of this divide-and-conquer system (P95 task duration) was firmly capped at 15.7 minutes.

By contrast, in the single-session solution without layering, once concurrency rose, the slowest task was directly dragged to nearly half an hour.

This system-level throughput does not come without cost. Multi-process concurrency and fine-grained state maintenance essentially trade more model invocation frequency and cache overhead for smoother overall execution and the liberation of human attention.

For software engineering, as long as developers can be rescued from endless context alignment, this incremental computing resource cost is worthwhile on the team's ledger.

>_ section 05

In closing

Over the past two years, the entire AI industry has been led astray by an almost anthropomorphic narrative. Many people instinctively assume that a good coding assistant should sit across the screen like a real person, replying instantly to every sentence and diligently reporting every bit of progress.

But the underlying laws of software engineering have never cared about social niceties; they recognize only state machines, pipelines, and deterministic delivery interfaces.

The most interesting part of DeepSeek's architecture proposal is that it questions instant replying itself.

It does not spend energy on how to make the large model speak more politely or make the typing animation in the terminal cooler, but instead moves scheduling rules, permission sandboxes, and caching mechanisms that computer systems have tested for decades unchanged into the large model architecture.

A truly mature industrial-grade agent does not need to be a chatterbox assistant that keeps people on edge in the R&D pipeline. It is enough for it to be an automated tooling system sunk at the bottom of the code repository, not grabbing attention, and delivering according to the rules.

Don't perform those flashy instant-reply tricks in the chat box; just quietly finish the dirty work in the background. Only when it can deliver silently will AI programming bid farewell to being a geek toy and mature into a reliable foundation in software engineering.

>_ Explain complex technology in a way you can understand.

>_ Moore Observation · Original production

Unauthorized reproduction prohibited

Disclaimer

This article provides an in-depth review and business logic analysis based on public materials, including corporate announcements, technical patents, Tianyancha, and authoritative media reports, with the aim of exploring technological trajectories and industry trends. The product parameters and performance descriptions referenced in this article are quoted from official disclosure statements and represent only theoretical analysis based on existing data, rather than definitive feedback from physical experience. Given that technology products (especially new energy vehicles and robots) involve software and hardware OTA iterations, should any relevant data differ from actual device performance, please refer to the company's official final release. The views expressed in this article are for reference only and do not constitute any basis for investment or purchase decisions.