DeepSeek drops a free coding agent that takes requests from GitHub

DeepSeek's Harness team has released an open-source coding agent that can take requests through GitHub and return with proposed changes, bringing AI into a team's daily workflow. ^[1]

Published on October 31, the software is called dsh-superagent-prototype and is designed for a single GitHub repository. ^[1] It listens to GitHub events and can optionally connect to Feishu, a workplace messaging service. ^[1] When an authorised person asks it to work, it creates a work item in its own agent session and directory, then can answer in the original conversation, including with a pull request, a formal proposal asking the team to review and merge code changes. ^[1]

The ambition reaches beyond another tool that writes code when prompted. DeepSeek's accompanying design describes a system that stays available, receives messages and delegates separate jobs, according to BigGo Finance's account of the team's technical article. ^[4] The useful change is continuity: a team could ask for work where it already discusses that work, rather than carry each task into a fresh chatbot conversation.

DeepSeek calls the release a "research prototype", not an official product or production-ready software. ^[1] The team warns that it may contain bugs, differs from its internal version and does not implement every idea in the design article. ^[1] How much of the full architecture is present in the public code, and which bug-fixing workflows work without operator changes, have not been established.

One coordinator, separate jobs

The design has two layers. A persistent Router handles incoming requests and coordinates interaction with people. ^[4] Workers receive individual assignments and handle them in separate contexts, according to BigGo Finance's account of the DeepSeek team's technical article. ^[4] Those assignments can include reproducing an issue, reviewing code or developing a feature. ^[4]

The public prototype documents a separate agent session and directory for each work item, although DeepSeek cautions against treating the published code as the complete architectural vision. ^[1]

That division addresses a practical problem with putting an agent into a busy team: accepting a request and doing the work are different jobs. A coordinator needs to remain responsive while a task takes time. Separate Workers give the design a way to move several pieces of work forward without turning every incoming message into an interruption of the same conversation. ^[4]

The proposed pull request is also an important boundary. It gives the agent a way to return a concrete result to the team, rather than merely announce that it has found a possible fix. The release describes opening pull requests, not a guarantee that the changes are correct. ^[1]

Listening is not permission

The prototype's rules put authorisation ahead of initiative. It should act only when asked by an allowed person or when a team-written rule permits the work. ^[1][3] For requests it infers rather than receives explicitly, the documented default is an observe mode: record what it would do without accepting the task. ^[1][3]

That gives operators a chance to inspect its judgement before allowing it to act. DeepSeek tells them to begin with narrow permissions and recorded-only proactive decisions, review those decisions and expand authority afterwards. ^[2][3] A message being visible to the agent is not, by itself, permission to do what it says.

The team's stated philosophy is to provide value while consuming as little human attention as possible. ^[2] Its documentation says the agent should speak when someone needs to act or can use a result, and acknowledges that an agent working for a team can waste the team's attention too. ^[2]

This is the right constraint. An assistant that generates a stream of marginal suggestions creates another queue for people to clear. Useful autonomy should reduce the decisions a team must make, while leaving people in control of which work the software may undertake.

According to BigGo's account, DeepSeek identified long-term memory, security and privacy, and human oversight of concurrent work as challenges for wider deployment. ^[4] Those questions become more pressing as the system gains access and takes on more tasks at once.

Open code, an early test

The MIT licence allows anyone to use, copy, modify, distribute, sublicense and sell the software, provided they include the copyright and permission notice. ^[5] It also supplies the code without warranty. ^[5] That gives other developers broad room to adapt the prototype, including commercially, without making it a finished service or granting rights to external tools it may connect to.

The performance evidence is narrower than the ambition. According to BigGo, DeepSeek said an internal instance was being used in daily research and development. ^[4] BigGo also said the team's preliminary comparison used simulated message streams and simulated time-consuming tools, rather than directly measuring real-world coding quality. ^[4] These are the team's reported findings, not an independent evaluation.

In that experiment, the team reported a 95th-percentile task completion time of 15.7 minutes for the super-agent approach, against 29.5 minutes for a conventional single-session setup, according to BigGo. ^[4] That measure describes the slower end of the tested tasks, not the average. The super-agent setup also used more cache-read tokens, the tokens retrieved from previously processed material. ^[4]

Those figures support investigating the coordination design. They do not establish that the public prototype produces useful bug fixes reliably. The next practical step is the one DeepSeek's own instructions set out: restrict permissions, observe its proposed decisions and review them before giving it more authority. ^[2][3]