The agent removed the coordinating step, not the reviewing oneAgent 移走的是「协调」那一步，不是「审查」那一步

DeepSeek just open-sourced Super-Agent, a free coding agent built to need "as little human attention as possible." But read the design: it automates coordinating the work, while someone still must review every result. The bottleneck didn't vanish — it moved to you. DeepSeek released the code on 2026-11-01, and the promise of saved attention is real; the catch is that the attention you save on coordinating the work comes back as attention spent reviewing it.

That distinction is the whole point of this piece. A "coding agent" is a program that writes and changes software on its own, the way a junior engineer would, instead of a person typing every line. When a vendor says its agent runs "for a whole team," the natural thing to hear is that the team's bottleneck — the step that limits how much work actually gets done — has been removed. It has not. It has moved. And where it moves to decides whether this kind of tool makes you faster or just busier.

The default read is that a self-running agent removes the human bottleneck

Here is the story most people take away from a launch like this: a smart agent now coordinates a team's coding by itself, so the humans are freed up and the team can suddenly do far more at once. Run ten agents, get ten engineers' worth of output. The limit used to be how many people you could hire and manage; now the limit is just how many agents you can spin up, which is effectively unlimited and nearly free.

If that were true, it would be one of the largest productivity shifts in software, and you would want to run as many agents as your budget allowed. It is worth taking the claim seriously enough to check it against the actual design — because the design, which DeepSeek published in full, tells a more specific story than the headline.

Here is what the design actually does, step by step

By DeepSeek's own description, Super-Agent "listens to GitHub and, optionally, Feishu" — meaning it watches a team's code repository and chat. When "someone allowed asks the agent for work," it "opens a work item, works on it in its own agent session and directory, and answers in the original conversation, for example with a pull request." A pull request is the standard unit of a proposed code change: a bundle of edits that a human reviewer reads and then accepts or rejects before it becomes part of the real software. Internally the system splits into a coordinator that routes requests and workers that carry them out, so several tasks can run at once.

Then comes the sentence that matters most. DeepSeek writes: "A web panel shows what needs a person." The agent does not merge its own work into the live codebase. It produces proposals and lays them out for a human to approve. DeepSeek is explicit that people stay "responsible for setting goals and reviewing the work."

So trace what is automated and what is not. Automated: noticing that work needs doing, picking it up, drafting the change, and formatting it as a reviewable proposal. That is the coordinating and the first draft — real labor, genuinely offloaded. Not automated: deciding whether the proposal is correct, safe, and worth keeping. That is the review, and it is handed back to you by design. The agent removed the step of organizing and writing; it kept the step of judging.

This is not a flaw in the tool. It is the honest shape of the tool. An agent you would trust to merge its own code with no human looking would be a very different and far riskier product. DeepSeek built the safer version, and the safer version keeps a human in the one seat that bounds everything else.

Reviewing is not free, and that is where the ceiling sits

The default read quietly assumes that review is cheap — that approving a change the agent wrote takes no real time. It does not. To accept a pull request responsibly, a human has to read the change, understand what it touches, and decide whether it is right. That takes minutes to hours depending on the change, and it cannot be skipped without turning "the agent does the work" into "the agent ships unreviewed code," which is the thing nobody actually wants.

Once you grant that reviewing costs time, the arithmetic flips. Total output that actually lands — code that gets merged and used — is not bounded by how many agents are drafting. It is bounded by how fast the humans can accept or reject what the agents draft. Launching a second agent doubles the drafting and doubles the proposals arriving at the panel. It does nothing to the rate at which a reviewer can clear them. The ceiling is review capacity, and more agents do not raise it; they just load it faster.

There is a piece of independent evidence worth naming carefully, because it is easy to overclaim. A general study called CooperBench, published in January 2026, found that coding agents working as a team had success rates on average 30% lower than when each agent did the tasks alone. That study did not test DeepSeek's Super-Agent — it is a separate, unrelated piece of research. So it is not proof about this product. But it is a signal pointing the same way: coordinating multiple agents has a cost, and more agents in a group is not automatically more good work out. Treat it as a reason to measure, not as a verdict.

A proactive agent fills the queue faster than it empties it

There is a second turn in the design that makes the review ceiling bind harder, not softer. Super-Agent is proactive. It does not only answer when summoned; it "acts only when asked or when a rule the team wrote allows it." That phrase cuts both ways. It is a sensible safety rail — the agent will not run wild, it follows rules you set. But it also means the agent can start work on its own, across a whole team's conversations, whenever a standing rule fires. A proactive agent is, by construction, a generator of review items. The more of the team's activity it watches, the more proposals it can produce without anyone asking.

DeepSeek saw this clearly and said so. Its own documentation warns: "An agent that can act for a whole team can also waste a whole team's attention." That is a remarkable thing for a maker to print next to its own launch, and it is exactly the mechanism described here. The attention the agent saves by coordinating and drafting can be spent right back — and then some — if it files more proposals than the team can review. The queue does not shrink. It fills faster.

It is also worth naming the quieter cost in that same design: to be proactive across a team, the agent reads the team's chats and repositories. That is a privacy and trust surface, not a feature to maximize. The more of a team's private conversation an agent watches so it can act without being asked, the more the team is relying on that watching behaving well. Treat the monitoring as a cost to weigh, not a dial to turn all the way up.

One more honest caveat belongs here. DeepSeek labels Super-Agent a "Research prototype for reference only, not an official DeepSeek product," and tells you to "treat it as research code, not production-ready software." So everything above describes a capability demonstration, not a reliability claim. It shows that an agent can coordinate a team's coding. It does not show that the reviewing step got cheaper, and that is the step that decides whether any of this makes a team faster.

The strongest version of the other side

The fair counter is not that the bottleneck disappears — it is that review time per unit of work can genuinely fall, not just move. For a disciplined team, the argument goes, the agent only acts on rules you wrote, it drafts changes you would have had to write yourself, and reading a finished diff is faster than specifying, writing, and self-checking it from scratch. If the drafts are good enough that review is fast skimming rather than rework, and if the flow of auto-opened proposals stays within what reviewers can clear, then the agent is a real net gain — you get the drafting for free and spend less total human time per shipped change.

That version can be true. Notice its conditions, though: draft quality high enough to skim, and proactivity throttled enough that the queue stays clearable. Both are empirical, and both are exactly what you should measure before trusting them. The counter does not break the thesis; it tells you which number proves or disproves it.

What this means if you are tempted to run a fleet of agents

If you are a solo builder or a small team weighing whether to point several autonomous coding agents at your work, the useful move is to stop counting agents and start counting throughput at the review step. Concretely: this week, measure your own merged-pull-requests-per-reviewer-hour — how many proposed changes one person can actually read, approve, and land in an hour. That number is your real capacity. Add agents only while it holds steady. If you add a second and third agent and the count of open, waiting proposals climbs while merges-per-hour stays flat, you have not expanded your output. You have moved your bottleneck from doing the work to clearing the queue, and lengthened the queue.

The general principle outlasts this one prototype, which is why it is worth holding onto. Whenever a tool promises to "take as little of your attention as possible," find the step it hands back to you, and measure your speed at that step. That retained step, not the flashy automated one, is what caps the whole system.

What would change my mind

This is a judgment, and it is falsifiable. I would change it if an independent evaluation — or a team's own logged data — showed that adopting an agent like Super-Agent raised accepted, merged output per reviewer-hour, meaning the time per accepted pull request actually fell, rather than merely increasing the number of open proposals waiting on a human. The place to look is independent, agent-specific benchmarks (CooperBench-style team evaluations, or SWE-bench-Multi-type tests) and published before-and-after team metrics on merged changes per reviewer-hour. A reasonable date to check by is 2027-03-31. Until a number like that appears, the safe read is that these agents move the bottleneck to review and do not yet make reviewing cheaper.

See the system. Build leverage. The leverage here is not the number of agents you can launch. It is how fast you can say yes or no to what they produce.