DeepSeek Super-Agent Opens PRs Without Being Asked

DeepSeek open-sourced dsh-superagent on October 31 under an MIT license, a research prototype coding agent that watches a GitHub repository, picks up authorized bug reports, writes a fix in an isolated Worker session, and opens a pull request without a prompt. The prototype uses a Router-Worker architecture in which one long-running Router session handles human-facing communication and dispatches tickets to parallel Workers, and it defaults to observe mode, where the agent logs what it would have done until a team enables auto mode with at least one matching team-written rule per action. DeepSeek's README states the prototype is not the company's internal system, runs Workers in danger-full-access mode as the OS user with no sandboxing or security audit, handles one GitHub repo at a time, and supports Feishu for chat integration only — no Slack or Discord.

DeepSeek just open-sourced a coding agent that doesn’t wait for you to type a prompt. Released October 31 under an MIT license, dsh-superagent watches your GitHub repository, picks up bug reports it’s authorized to handle, codes a fix in an isolated session, and opens a pull request — entirely on its own. The prototype is on GitHub now https://github.com/deepseek-ai/dsh-superagent-prototype and it’s free to run. The Bottleneck Isn’t the Model Anymore Here’s the insight buried in DeepSeek’s philosophy document: a developer can realistically track three to five active agent sessions at once. Model quality keeps improving. Model costs keep dropping. But a developer still has one pair of eyes. Every coding agent today — Claude Code, Cursor, Codex — is reactive. You prompt it, it responds. You’re the scheduler. You’re the one watching five terminal windows and deciding which session needs your attention. That ceiling doesn’t go away just because the models get smarter. DeepSeek’s answer is a Router-Worker architecture . One long-running Router session handles all human-facing communication and dispatches work. Multiple isolated Worker sessions run in parallel, each handling one task. You watch one Router. It coordinates the rest. Human attention scales. How It Actually Works The Router is deliberately constrained. It has a small tool set, shell commands capped at a few seconds, and it never writes a line of code. Its job is to receive events from GitHub and optionally Feishu , evaluate whether they’re authorized work, and dispatch Tickets to Workers. Workers are the opposite: full tool access, isolated working directory, runs as the OS user. When a Worker picks up a bug report, it tries to reproduce the issue, writes a fix, runs tests, and opens a pull request. It posts results back through the Router to the original conversation. The developer sees the PR; they don’t have to manage the session that created it. Each Worker also subscribes to the threads it cares about — a PR, a chat thread — so follow-up events go straight to that Worker without clogging the Router. The architecture keeps the Router fast and the Workers focused. Observe Mode First Proactive work defaults to observe mode . The agent watches, logs what it would have done, and does nothing. That’s intentional. You audit the logs, check the judgment, and only enable auto mode once you trust the decisions. In auto mode, each proactive action requires at least one matching team-written rule. Triggers include GitHub issues, PR comments, CI results, and Feishu messages. The recommendation from DeepSeek: start with a narrow allowlist and keep inferred work in observe mode until you’re confident. What It Is Not Be precise about what you’re getting. This is a research prototype https://dev.to/paullovelace/deepseek-super-agent-a-proactive-open-source-coding-agent-prototype-what-it-actually-is-and-438a , not a product. It is not the internal DeepSeek system — the README says so explicitly. Workers run in danger-full-access mode as the OS user, meaning no sandboxing and no security audit. One GitHub repo at a time. Feishu for chat integration only — no Slack, no Discord. That last point is a real gap for most Western dev teams. Feishu is common in Chinese tech companies and not much else. If your team lives in Slack, this prototype won’t hook into your existing workflow without modification. How to Try It It runs on top of DeepSeek Harness https://devops.com/deepseek-wants-coding-agents-to-stop-waiting-for-instructions , the open-source agent framework released in August. Install it, point dsh-superagent at your repo, and start in observe mode: npm install -g @deepseek-ai/dsh dsh web Install the dsh-superagent bundle on a running Harness instance, then point it at your repo. DeepSeek’s suggested path is agent-assisted: run any coding agent and tell it to read SETUP.md in the repository. Keep your allowlist narrow and start in observe mode. The Right Framing Most coverage has leaned into the “DeepSeek vs Anthropic” angle. That’s not wrong — Bloomberg positioned this directly against Claude Code https://www.bloomberg.com/news/articles/2026-11-01/deepseek-drops-enhanced-coding-agent-with-aim-to-rival-anthropic — but it misses what’s actually interesting here. The attention budget framing is correct. Reactive agents have a ceiling. You can make them smarter, faster, and cheaper, but they still require a human prompt to start. At some point, the value of running more agents in parallel exceeds what a human supervisor can capture. A proactive coordination layer is the right direction. This prototype has real gaps — no sandboxing, Feishu-only, single-repo limit. But the architecture is worth studying now. The problems it’s solving are going to matter more as the industry moves toward multi-agent workflows.