DeepSeek's Super-agent Takes Coding Requests From GitHub. How Autonomous Is It?

A teammate reports a broken feature in GitHub. An agent picks up the request, works on a fix in its own session and returns to the same conversation with a result ready for review. Meanwhile, the team carries on.

That is the workflow behind DeepSeek's newly published dsh-superagent prototype. It works on one GitHub repository and can optionally receive messages from Feishu or Lark. DeepSeek labels it “Research prototype for reference only, not an official DeepSeek product.” Users are asked to review and adapt the code before use.

For anyone familiar with the everyday DeepSeek assistant, this is a different proposition: an agent that can manage more of the conversation around coding work, leaving people to set direction and judge results. The repository makes that workflow available to study.

Three related systems, three different jobs

The familiar chatbot answers questions. DeepSeek Harness is an open-source agent environment in worldwide public preview. Super-agent is a research bundle that runs inside Harness and adds a team workflow around repository work.

The bundle requires its own setup, accounts, policies and model provider. Alongside it, DeepSeek published a design essay, Exploring Super-agent Design: Towards a More Autonomous Agent System. The README explains that the public code was adapted from the internal version and implements only part of the broader design.

From a bug report to a reviewable fix

Consider a developer asking the agent to fix a checkout button that fails on mobile. This example follows the documented workflow; Choosely's assessment is based on source inspection.

The authorization rules determine whether the person and request may start work. An accepted request becomes a Ticket, the system's record of an authorized job. Its Mandate records the scope and basis for permission.

A central coordinating session, or Router, assigns the job to a Worker with its own session and directory. The Worker can investigate and prepare a result, potentially a pull request: a proposed code change that the team can inspect. Results return through the original conversation, and a panel highlights work awaiting an answer or review.

Later comments in a subscribed discussion can reach that Worker directly. The existing Mandate continues to define its authority. The Worker is expected to handle requests within that scope and hand broader work back for routing. That lets a conversation continue while keeping a record of what the agent was authorized to do.

The Router coordinates; Workers carry out the jobs

The design principle is to make the agent consume less team attention. Separate Workers let independent jobs progress without filling one shared conversation with every implementation detail. The Router handles coordination and brings back useful results or questions.

People still decide what counts as a good fix. The intended benefit is spending less time moving instructions between sessions and more time judging the work that comes back. Measuring that benefit would require real team use, including the time spent reviewing and correcting results.

The public Router retains shell access. Its architecture guide describes avoiding code reads as a prompt rule. That detail matters when interpreting diagrams that separate coordination from execution: the released coordinator still has tools capable of acting on its environment.

Proactive work starts with team-written rules

By default, inferred proactive work uses observe mode: the system assesses candidates and records what it would accept. Explicit requests from permitted people work in every mode.

Switching to auto allows qualifying inferred candidates to become tasks when enabled rules match. Teams can first inspect those recorded judgments, then decide whether to let selected kinds of work proceed automatically.

Operators have a direct brake: Stop in the panel acts on the Ticket directly, withdraws its Mandate and leaves it ended. Starting work there again requires a new acceptance. A stop message written in a conversation goes through the evaluation path.

Policy changes notify affected live tasks, and ended tasks undergo revalidation before resuming. Pausing processing holds dispatch, input delivery and replies while an Executor turn already running continues.

Permission to work is not a secure sandbox

The deployment guide says both Router and Worker presets run with danger-full-access as the operator's operating-system user. Workers can read that user's home directory and execute programs by path. Task directories organize work; credential wrappers select the accounts used by default. Neither one isolates the process.

DeepSeek recommends a dedicated operating-system account containing only the agent's credentials. This matters because the process inherits that account's access to files and programs. The warning describes the documented operating posture; Choosely has performed source inspection only.

The defaults also favor human merging. The agent never enables auto-merge as its own account by default, enabling it requires another account's CLI, and setup recommends that people merge the changes themselves.

The execution guide places any configured auto-merge conditions in delivery instructions. GitHub branch protection supplies enforced approval requirements.

Running it requires a developer's setup

The public bundle documents GitHub and optional Feishu sources, a dedicated Harness profile, a local state directory and recovery behavior. Setup requires developer tooling, a configured model provider and a dedicated GitHub user account with write access. The supported repository host is github.com; GitHub Enterprise Server falls outside the documented support.

The repository's MIT license permits reuse under its terms. Model usage and infrastructure carry their own costs. The bundle uses the Harness profile's default model unless evaluation or execution settings select another, so capability and running costs depend on the deployment.

The public prototype, internal research system and broader design ideas each need to be judged on their own evidence. The README explicitly identifies some designs in the essay as future development directions.

A performance comparison with Claude Code, Codex or Devin remains open. Our source review supports an explanation of Super-agent's workflow. Comparative coding quality, total cost and review effort require a separate, matched test.

Choosely's early assessment

Super-agent earns attention as a public example of how coding agents might fit into a team's existing conversations. Developers building that kind of workflow have something concrete to study. Founders can see which responsibilities remain theirs: defining authority, protecting the environment and accepting the result.

For an ordinary user seeking a dependable coding assistant, the current release asks for substantial technical ownership. The promise of fewer interruptions is appealing. Whether it delivers good work with less supervision remains a question for real, independently documented use.

Evidence note: Source-based early assessment of repository revision 6337fc8. Choosely did not install or run the prototype.