Why can't the smartest code assistant respond to your messages in seconds?

Many engineers who integrate AI into their daily R&D work have shared a similar frustrating experience: right after finishing writing a prompt, they get up to get a glass of water, only to come back and find the process in the terminal has long been stuck halfway, with the cursor sitting lonely on the screen, waiting for them to manually press Enter to confirm.

Over the past period, promotions for various programming assistants on the market have all emphasized how fast the generation speed is: type a line of natural language, the large model instantly spits out hundreds of lines of code, and all test cases in the terminal show green. But in real software teams, this seemingly stunning instant feedback is turning into a high-frequency energy tug-of-war.

Every time the agent reads a file, modifies a line of configuration, or runs a command, it pops up to ask for approval. You just finished explaining the business background clearly in the group chat, and when you turn to the code review tool to submit modifications, you have to re-enter all the context again.

Once the task involves cross-module troubleshooting or dependency refactoring, the session window will soon be overwhelmed by dozens of rounds of context, and a slight oversight will lead to irrelevant answers.

This awkward situation was explicitly pointed out in 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 titled Exploration of Super-agent Design: Moving Towards a More Autonomous Agent System on its official WeChat public account, systematically introducing a set of research prototype design for software engineering.

According to the official long article, the team did not spend much time emphasizing how fast the large model can run code at the beginning, but clearly put forward a core principle: occupy human attention as little as possible, and deliver as much value as possible.

This long technical article directly points out the most embarrassing bottleneck of current AI programming: as the single-point generation capability of the underlying model becomes stronger and stronger, the bottleneck limiting the output scale has long changed. What really restricts the team is the attention limit of human developers.

Forcing agents to reply instantly and ask for approval from humans in the chat box often only exhausts people. Moving them to the background and building a distributed system that can schedule itself and is isolated from each other is the right path for AI to truly integrate into software engineering.

01

The Faster AI Writes Code, the Busier Humans Get

In the existing programming agent architecture, the single-session serial mode is never low-cost, as it consumes huge human energy.

For current mainstream code assistants, whether they are command line tools or desktop plugins, their underlying logic is basically bound to a single thinking and action loop.

This small dialog box is stuffed with too many miscellaneous tasks: it needs to understand human language, run command lines to read and write files, and withstand the ultra-long context of dozens of rounds of tool calls.

According to the observation of the DeepSeek Harness team in the long article, a human engineer can usually only maintain 3 to 5 active sessions that they can deeply memorize and effectively follow up on in actual work.

Once this number is exceeded, the human brain cannot maintain the continuity of multiple contexts, and can only be 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. Product managers may propose plan adjustments in instant messaging groups, architects give two lines of comments in code reviews, and CI pipelines report compilation failures in the background.

Under the single-session architecture, these three pieces of information are scattered across different platforms, the agents are isolated from each other, and the only synchronization link is the overworked human developer in the middle.

This design turns developers into cheap context transporters and approval tools that perform high-frequency click confirmations. The model seems to reply instantly in front of the screen, but in fact, it pushes the most cumbersome multi-task state management to humans.

When most of the engineer's energy is spent checking the execution intention of the model a few minutes ago, the so-called high efficiency turns into a hidden internal consumption of energy.

02

Fully Separate the "Scheduler" from the "Worker"

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

The core of the prototype solution disassembled in the long article is to split the system into two layers: a Router that is resident at the front end and is responsible for overall management, and multiple independent Workers mounted at the back end. The two are clearly decoupled in terms of responsibilities, permissions and model resource configuration.

The Router resident in the group chat or repository background acts as the scheduling hub of the system. It is only responsible for reading incoming event messages, evaluating intentions, and generating work orders with strict permission boundaries, which is officially called a Ticket with authorization letter.

The Router itself does not even need to be configured with underlying high-risk execution tools, and only needs to run a lightweight model in terms of resource allocation. It does not touch specific code modifications or participate in long-time logical reasoning, the purpose of which is to ensure that the global interaction channel is unobstructed, so that it will not fall into deadlock due to a certain complex task.

It is the Worker that automatically starts in the background after receiving the work order that really takes on the tough tasks. Each Worker has an independent execution session and an isolated workspace.

As long as the environment allows, the system will automatically assign an independent Git temporary working tree to the Worker, allowing it to operate freely in a clean code copy, modifying configurations and running tests without affecting the main branch.

This physical isolation directly cuts off mutual pollution between long tasks.

Developing a new interface and troubleshooting online errors can be carried out in parallel by different Workers in the background. Even if one of them crashes due to a code infinite loop, it will not pollute the main branch, let alone confuse the main control context of the Router.

All the tedious and heavy work is digested by isolated sub-nodes in the background, and the scheduler uniformly submits results to humans externally, which provides reliable engineering support for multi-task parallelism.

03

Don't Let All Information Disturb the Human Brain

In addition to separating execution and scheduling, how to maintain restraint in the complex torrent of messages is the key to determining whether agents can truly be integrated into teams.

In the daily collaboration environment, group chat discussions, code submission pipelines, and automated test errors are generated all the time. If the agent acts like a new intern who is keen on showing up and interrupts every message, the attention of the entire R&D team will be instantly flooded by notifications.

DeepSeek introduces an event filtering and pass-through mechanism similar to traditional network protocols in its design. When there are too many messages, the system first uses a few lines of lightweight code rules to block idle chat and noise. Only real events that hit the whitelist will be handed over to the large model for intention understanding.

For potential tasks inferred from discussions, the system sets an extremely restrained default level in permission control. DeepSeek adds a strict restriction for active order receiving: observation mode is enabled by default.

Even if the large model immediately spots a defect in the code that needs refactoring, it will only quietly note in the local log that this task can be handled, and will never take the initiative to claim the work order to modify the code without human approval.

Another extremely practical engineering design is subscription pass-through. When a Worker claims a Pull Request, the system will automatically establish a many-to-many event mapping at the underlying layer.

All subsequent review comments for this PR will be directly delivered by the underlying system to the Worker process responsible for the task, without going through the Router for secondary forwarding.

According to the simulation test data released by the DeepSeek Harness team, after eliminating repeated disturbances to the main control, the number of redundant decision-making times of the scheduling hub has decreased by about 30%, and the computing resources required for reading cache have also been reduced by more than one third.

Only when the communication link is compressed within the context of the actual executor, can the system remain quiet in multi-party collaboration.

04

Only with Cost-effectiveness Can the Solution Be Adopted by Teams

When the technical solution evolves from standalone demonstration to full-time team deployment, the final assessment never focuses on how smart a single conversation is, but on the robustness and operating efficiency of the entire system.

In the blind imagination of many teams, the more versatile the agent is, the better, ideally with unlimited memory and the ability to think autonomously non-stop in the background. But in the real computing budget, this castle in the air will disintegrate at any time due to a network flicker or process crash.

What DeepSeek shows in the long article is a typical disenchanted engineering perspective. To deal with inevitable freezes and exceptions during long-time operation, the system completely separates state storage from model computing.

The authorization status of tasks, work order progress and interaction history are all persisted to a local lightweight database, and 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 to advance, without requiring humans to re-enter all the context.

In the team's simulation scheduling experiment for about 300 messages and 20 work requests, this divide-and-conquer system showed obvious engineering advantages in task completion time. When facing high concurrent message impact, the tail latency (P95 task duration) of this divide-and-conquer system is firmly controlled within 15.7 minutes.

In contrast, for the single-session solution without layering, once the concurrency rises, the slowest task is 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 use more model invocation times and cache overhead in exchange for stable overall execution and liberation of human attention.

For software engineering, as long as developers can be saved from endless context alignment, this incremental overhead of computing resources is cost-effective in the team's budget.

05

Closing Remarks

In the past two years, the entire AI industry has almost been led astray by anthropomorphic narratives. Many people instinctively think that a good programming assistant should sit opposite the screen like a real person, reply to every sentence instantly, and report every progress eagerly.

But the underlying rules of software engineering never follow human sophistication, they only recognize state machines, pipelines and deterministic delivery interfaces.

The most interesting part of DeepSeek's architecture proposal is that it questions the very value of instant reply.

It does not waste energy on making the large model speak more politely, or making the typing animation in the terminal more cool, but directly moves the scheduling rules, permission sandboxes and caching mechanisms of computer systems that have been tested for decades into the large model architecture.

A truly mature industrial-grade agent does not need to be a chattery assistant that makes people nervous in the R&D workflow. It is enough to act steadily as a set of automated tools that sink at the bottom of the code repository, do not grab attention, and deliver results according to rules.

Stop performing those flashy instant reply tricks in the chat box, and finish the dirty work steadily in the background. Only when AI programming can deliver results silently, can it bid farewell to being a geek toy and become a reliable cornerstone in software engineering.

This article is from WeChat public account"Moore Observation", written by He Yuzhi, and published with authorization from 36Kr.